La stack technique : ce qui fait tourner votre outil
Votre application repose sur des briques standard, libres et répandues. Rien de propriétaire, rien qui vous enferme : n'importe quel développeur peut reprendre le projet. Voici ce que j'utilise, et surtout pourquoi.
Le principe. Je ne vous livre pas un accès à ma plateforme : je vous livre une application, son code et son hébergement, construits avec des outils que tout prestataire sait maintenir. C'est ce qui rend la sortie possible, et donc la confiance.
L'application
- Next.js et React pour l'interface et le serveur. Un framework très répandu, soutenu par une grande communauté : trouver quelqu'un pour reprendre le code n'est pas un sujet.
- TypeScript partout. Le code est typé, donc vérifié avant même d'être lancé, ce qui limite les erreurs bêtes qui finissent en bug en production.
- Tailwind CSS pour le style, avec un design system maison pour garder des écrans cohérents d'un module à l'autre.
Les données
- PostgreSQL, la base de données open source de référence. Vos données sont dans un format standard : vous pouvez les exporter, les interroger ou les migrer à tout moment, sans passer par moi.
- Prisma pour décrire le schéma et appliquer les migrations. Chaque évolution de la base est un fichier versionné et relu avant d'être appliqué.
- Recherche intégrée à Postgres (full-text) : pas de moteur de recherche supplémentaire à payer ni à maintenir.
- Stockage compatible S3 pour les pièces jointes, chez l'hébergeur de votre choix.
Les tâches de fond
- Un worker pg-boss, qui s'appuie sur la même base PostgreSQL, gère ce qui ne doit pas bloquer l'écran : relève des boîtes mail, rappels de relance, calcul des délais de réponse. Pas de service de file d'attente en plus.
- Mails entrants et sortants en IMAP et SMTP standards : vous gardez votre messagerie actuelle. Les identifiants des boîtes sont chiffrés en base.
La sécurité
- Authentification avec rôles et droits gérés à un seul endroit du code, et double authentification (TOTP) imposée aux responsables.
- Base jamais exposée sur Internet : elle vit dans un réseau interne, seul le serveur web est joignable.
- HTTPS automatique avec Caddy, qui obtient et renouvelle les certificats tout seul, et ajoute les en-têtes de sécurité usuels.
- Serveur durci : connexion SSH par clé uniquement, pare-feu, blocage des tentatives répétées (fail2ban), mises à jour de sécurité automatiques.
- Aucun secret dans le code : mots de passe et clés vivent dans la configuration du serveur, jamais dans le dépôt.
Docker : un outil identique partout
Toute la plateforme tourne dans des conteneurs Docker décrits par un fichier docker-compose.yml : application, worker, base de données, serveur HTTPS. Concrètement :
- ce qui tourne sur mon poste est ce qui tourne en production : moins de « ça marchait chez moi » ;
- une instance se recrée sur un autre serveur en quelques commandes, ce qui rend le changement d'hébergeur simple ;
- chaque client a sa propre instance isolée : ses données ne cohabitent jamais avec celles d'un autre.
GitHub : le code, la qualité, le déploiement
- Le code source est versionné dans Git, avec l'historique de chaque modification. À la passation, vous en recevez une copie complète.
- GitHub Actions exécute des contrôles à chaque changement : vérification des types, analyse du code (lint), compilation. Si l'un échoue, rien n'est mis en ligne.
- Une fois les contrôles verts, le déploiement est automatique vers le serveur, par une connexion SSH dédiée. Une mise à jour est donc reproductible, et non une manipulation à la main.
L'hébergement
Le choix se fait selon votre situation, et il est réversible :
- Un serveur privé virtuel (VPS) en France, typiquement chez OVH : le plus simple, hébergement et données en France.
- Votre propre cloud si vous en avez déjà un (AWS par exemple) : l'application s'y installe de la même façon.
- Votre infrastructure si vous préférez tout garder chez vous.
Le nom de domaine et le DNS restent à votre nom. Un tunnel Cloudflare peut servir à publier un service sans ouvrir de port sur le réseau, utile pour une installation sur site.
Sauvegardes et exploitation
- Sauvegarde nocturne de la base avec restic : dépôt chiffré, stocké hors du serveur, conservation de 7 sauvegardes quotidiennes, 4 hebdomadaires et 6 mensuelles.
- Vérification automatique de l'intégrité des sauvegardes, et une restauration testée avant la mise en service.
- Une zone d'administration pour suivre l'état des conteneurs, des certificats et de la dernière sauvegarde.
- Statistiques de visite respectueuses sur le site vitrine avec Plausible, sans cookie.
Une base commune, des modules à la carte
La plateforme est un monolithe modulaire : un socle commun (comptes, droits, contacts, notes, pièces jointes, journal d'activité, rappels) et des modules métier que l'on active selon vos besoins : CRM, helpdesk, prise de rendez-vous, gestion de projet, stock et commandes, devis et facturation. Un module que vous n'achetez pas n'est pas dans votre instance. Un besoin particulier devient un module sur mesure, bâti sur le même socle.
Ce que ça change pour vous
| Question | Réponse |
|---|---|
| Puis-je changer de prestataire ? | Oui : stack standard, code et documentation fournis |
| Puis-je récupérer mes données ? | Oui : une base PostgreSQL standard, exportable |
| Où sont hébergées mes données ? | Où vous le décidez, en France par défaut |
| Que se passe-t-il si je vous quitte ? | L'application continue de tourner, sans licence à payer |
Une question sur un point précis de la stack, ou sur la compatibilité avec votre infrastructure ? Écrivez-moi via la page de contact.