Introduction
Le modèle SaaS domine le marché des outils métier, mais il présente des inconvénients concrets pour les TPE/PME : abonnements récurrents, dépendance à un tiers, et perte de contrôle sur ses propres données. Le projet open source QuotigyDash — une solution de facturation et de devis construite avec Laravel 11 — illustre une alternative sérieuse : une application distribuée en deux éditions, desktop et serveur, avec paiement unique et hébergement autonome.
Cet article analyse les choix d'architecture réalisés dans ce projet et propose un guide pratique pour répliquer cette approche sur vos propres applications Laravel.
Source originale : QuotigyDash sur DEV.to par Fabrizio Pavone.
1. SQLite ou MySQL : choisir la bonne base selon l'édition
L'un des premiers choix structurants est celui de la base de données. QuotigyDash adopte une stratégie différenciée :
- Édition Desktop → SQLite embarqué
- Édition Serveur → MySQL sur VPS ou serveur dédié
Pourquoi SQLite en desktop ?
SQLite ne nécessite aucun processus serveur. Le fichier de base de données est local, portable, et fonctionne intégralement hors ligne. Pour une application Electron embarquant PHP 8.4, c'est le choix évident : zéro configuration pour l'utilisateur final, démarrage immédiat.
Dans Laravel, la bascule est triviale via .env :
# Édition desktop
DB_CONNECTION=sqlite
DB_DATABASE=/absolute/path/to/database.sqlite
# Édition serveur
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=quotigydash
Limites de SQLite en production
SQLite reste mono-écriture et peu adapté à la concurrence. Dès que plusieurs utilisateurs accèdent simultanément à l'application (cas serveur partagé), MySQL ou PostgreSQL s'imposent. La règle est simple : SQLite pour le poste unique, MySQL/PostgreSQL pour le multi-utilisateur.
Conseil pratique : rendre les migrations compatibles
Pour maintenir une seule base de code, évitez les types SQL spécifiques à un moteur dans vos migrations. Privilégiez les méthodes génériques de Laravel (string, integer, json) plutôt que mediumText() ou tinyInteger() qui se comportent différemment selon le driver.
2. Packager Laravel dans Electron pour une application desktop
Emballer une application Laravel dans un exécutable Windows via Electron est une approche moins courante mais parfaitement viable. Voici la mécanique retenue par QuotigyDash.
Architecture générale
[Electron (Node.js)]
└── Spawn d'un processus PHP 8.4 embarqué
└── Laravel tourne sur un port local (ex: 127.0.0.1:8080)
└── SQLite local comme base de données
Electron joue le rôle de wrapper : il lance PHP en arrière-plan au démarrage, ouvre une fenêtre BrowserWindow pointant vers http://127.0.0.1:8080, et tue le processus PHP à la fermeture.
Points d'attention
Embarquer PHP 8.4 : il faut distribuer un binaire PHP compilé pour Windows (disponible sur windows.php.net), avec les extensions nécessaires (pdo_sqlite, mbstring, openssl…). Le dossier PHP est inclus directement dans le package Electron via extraResources dans electron-builder.
Le fichier .env : en mode desktop, il doit être généré automatiquement au premier lancement si absent, avec une APP_KEY aléatoire. Ne jamais le shipper dans le package.
Les assets : exécutez npm run build (Vite) avant de packager. Les assets compilés doivent être inclus dans public/build.
Mises à jour : prévoyez un mécanisme de vérification de version. Electron propose autoUpdater pour les mises à jour silencieuses depuis un serveur de releases.
3. Déploiement sur Raspberry Pi et serveurs légers
L'édition serveur de QuotigyDash supporte explicitement le Raspberry Pi, ce qui ouvre la voie à un hébergement local en entreprise pour moins de 100 €.
Prérequis sur Raspberry Pi OS (64 bits recommandé)
# PHP 8.4 + extensions Laravel
sudo apt install php8.4 php8.4-cli php8.4-fpm php8.4-mysql \
php8.4-mbstring php8.4-xml php8.4-curl php8.4-zip
# Composer
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
# MySQL ou MariaDB
sudo apt install mariadb-server
Déploiement Laravel standard
git clone https://github.com/votre-repo/app /var/www/app
cd /var/www/app
composer install --no-dev --optimize-autoloader
cp .env.example .env
php artisan key:generate
php artisan migrate --force
php artisan storage:link
php artisan config:cache && php artisan route:cache
Nginx comme reverse proxy
server {
listen 80;
server_name app.local;
root /var/www/app/public;
index index.php;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
}
Sauvegardes automatisées
Pour une TPE, une sauvegarde quotidienne suffit. Avec spatie/laravel-backup :
composer require spatie/laravel-backup
Puis dans le scheduler Laravel (app/Console/Kernel.php ou via routes/console.php en Laravel 11) :
Schedule::command('backup:run')->dailyAt('02:00');
Les sauvegardes peuvent être envoyées sur un disque S3 compatible (Backblaze B2, par exemple) pour une rétention hors site à faible coût.
4. Conformité et signatures PDF : les points de vigilance pour les TPE/PME
QuotigyDash intègre deux fonctionnalités avancées directement utiles aux entreprises françaises et italiennes : la signature numérique des PDF et l'export FatturaPA XML (norme italienne de facturation électronique).
Génération de PDF signés avec Laravel
Pour produire des PDF professionnels depuis Laravel, la combinaison barryvdh/laravel-dompdf + signature via setasign/fpdi et setasign/fpdf est courante. Pour une signature numérique conforme eIDAS, il faut un certificat qualifié (X.509) et une bibliothèque comme sop/asn1 ou une intégration avec un prestataire de signature.
Pour les usages courants en France (devis et factures internes), une signature visuelle avec cachet suffit légalement si elle est associée à un système de traçabilité (numéro unique, date, hash du document).
Facturation électronique : le contexte français
La France déploie progressivement l'obligation de facturation électronique B2B (PPF/PDP). Si vous construisez une solution de facturation self-hosted, anticipez dès maintenant :
- Format Factur-X (PDF/A-3 avec XML embarqué) pour les échanges
- Intégration avec le Portail Public de Facturation ou un PDP agréé
- Conservation des factures pendant 10 ans (obligation légale)
Ces contraintes poussent à concevoir la couche de stockage et d'archivage dès le début, pas en fin de projet.
Conclusion
L'approche adoptée par QuotigyDash — une seule base de code Laravel déclinée en édition desktop (Electron + SQLite) et serveur (VPS/Raspberry Pi + MySQL) — est reproductible et pertinente pour de nombreux projets métier. Elle permet de proposer à ses clients un outil qu'ils possèdent réellement, sans dépendance à un SaaS tiers.
Les points clés à retenir :
- SQLite pour le poste unique hors ligne, MySQL/PostgreSQL pour le multi-utilisateur
- Electron comme wrapper desktop léger, avec PHP embarqué
- Raspberry Pi comme serveur local économique pour les petites structures
- Sauvegardes automatisées et conformité réglementaire à prévoir dès la conception
Chez MulerTech, nous accompagnons les TPE/PME dans la conception et le déploiement d'applications Laravel sur mesure, qu'elles soient hébergées sur nos serveurs ou directement chez le client. Contactez-nous pour en discuter.
