Fiabilité & continuité de service
Conçu pour que le terrain ne s'arrête jamais.
Le flux critique (la prise de commande sur le terrain) continue de fonctionner même si tout le reste tombe, y compris nos propres serveurs. Le reste suit la même logique : infrastructure managée par des opérateurs spécialisés, hébergée à Francfort, base restaurable à la seconde près, données isolées par client à chaque requête.
| Profil | Force de vente | Commandes / mois | Écritures en base / min |
|---|---|---|---|
| Laboratoire nationalUne marque, un pays, une force de vente | 40 | 7 000 | 0,7 |
| Groupe multi-marquesPlusieurs catalogues, plusieurs réseaux | 150 | 30 000 | 2,8 |
| Groupe européen, plusieurs paysLe dimensionnement cible, pas un client actuel | 500 | 110 000 | 10,4 |
Au plus haut de cette échelle : une écriture en base toutes les six secondes.
Un PostgreSQL de production traite cette charge sans y penser. Multiplier la force de vente par douze ne change pas la nature du problème : le débit d'écriture n'est jamais ce qui met un outil comme celui-ci en difficulté. Ce qui change est ailleurs, et c'est l'objet des sections suivantes.
Faites défiler la figure →
01 · Le scénario redouté
« Le serveur tombe pendant une heure. » Rien ne se perd.
L'application mobile des commerciaux est offline-first. Toutes les lectures sont locales : consulter une fiche pharmacie ne déclenche aucun appel réseau. Toutes les écritures passent par une file locale persistée sur disque, photos et mémos vocaux compris, qui survit à un redémarrage du téléphone. Une indisponibilité serveur d'une heure, ou d'une journée, retarde uniquement le moment où le siège voit les données.
L'aire ambrée est la seule chose que l'incident produit : des commandes déjà saisies, déjà sur le disque du téléphone, qui attendent d'être transmises. Elle se referme seule au retour du réseau, sans ressaisie et sans bouton à cliquer.
Faites défiler la figure →
Synchronisation automatique
Elle se répète jusqu'à réussir : au retour du réseau, au retour de l'application au premier plan, et périodiquement. Les tentatives s'espacent d'elles-mêmes, sans aucune intervention de l'utilisateur.
Aucun doublon possible
L'identifiant de chaque commande est généré sur le téléphone et sert de clé primaire en base. Si la même commande est envoyée deux fois (coupure en plein envoi), le serveur la reconnaît et l'ignore.
Aucune limite, aucune expiration
Une journée entière de commandes hors ligne attend le retour du réseau, puis repart seule. Aucune ressaisie, aucun bouton à cliquer.
La même heure d'indisponibilité, des deux côtés.
La réponse honnête à « et si le serveur tombe ? » n'est pas une promesse de disponibilité (tout le monde en affiche une), mais ce que devient concrètement la journée de vos commerciaux pendant l'incident, et ce qu'il reste à faire après.
Outil connecté classique
Référence marchéCoût côté outil connecté · 60 minutes de terrain perdues, le temps de ressaisie, et les commandes oubliées au passage.
Salesia
Offline-firstCoût côté Salesia · le siège voit les données avec une heure de retard. C'est tout.
Le même raisonnement vaut pour une panne d'une journée : la file locale n'a ni taille maximale, ni date d'expiration.
Faites défiler la figure →
Ce que l'incident vous coûte
Que le siège voie les commandes du terrain en temps réel, et que les synchronisations avec vos autres outils avancent. Les deux reprennent seules.
Et ce qu'il ne vous coûte pas
Consulter un portefeuille, un catalogue, un historique, un agenda. Saisir une commande, un compte rendu, une photo, un mémo vocal. Autrement dit : la tournée.
02 · Infrastructure
Opérée par des spécialistes, pas par nous.
Salesia n'opère aucun serveur physique et n'auto-héberge aucune base de données. Chaque couche repose sur un opérateur dont c'est le métier, avec ses propres équipes d'astreinte 24/7 : les mêmes fondations (AWS, Cloudflare) que des milliers de SaaS établis.
| Couche | Technologie | Opérateur | Localisation |
|---|---|---|---|
| Base de données | PostgreSQL 17 | Neon (sur AWS) | Francfort (UE) |
| API | Node.js / Hono | Render | Francfort (UE) |
| Application web | SPA statique servie par CDN | Render | CDN mondial |
| Fichiers | Stockage objet S3-compatible | Cloudflare R2 | Juridiction UE |
| Application mobile | Native iOS | Distribution Apple | Sans objet |
La base scale toute seule
Le compute PostgreSQL s'ajuste automatiquement à la charge, sans intervention ni interruption de service. Le stockage est répliqué par l'opérateur.
Le front ne peut pas « tomber »
L'application web est un ensemble de fichiers statiques servis par CDN : même si l'API est indisponible, l'interface se charge.
Vérifiez leur disponibilité vous-même
Pages d'état publiques, mises à jour par les opérateurs.
La montée en charge n'est pas votre problème.
Le compute PostgreSQL s'ajuste automatiquement à la charge, sans intervention et sans interruption de service. Concrètement : la synchronisation matinale d'une force de vente et le calcul des indicateurs de fin de mois ne demandent aucune planification de votre côté.
Une journée de charge, sans planification côté client
L'ajustement est opéré par la plateforme de base de données : pas de fenêtre de maintenance, pas de redimensionnement à demander, pas de surdimensionnement payé 24h/24 pour absorber deux pics quotidiens.
Faites défiler la figure →
03 · Isolation des pannes
Une défaillance locale ne devient jamais une panne générale.
Le principe de conception est le cloisonnement. En pratique, la menace la plus réaliste n'est pas la panne matérielle (elle est déléguée à l'opérateur), mais un import tiers qui part en vrille et emporte le service avec lui.
API · prise de commande
Toute erreur fatale est détectée et entraîne un redémarrage immédiat par la plateforme, sans humain.
Douze au total, planifiés indépendamment, exécutés hors de l'API.
Un import qui échoue ou qui ralentit ne peut pas dégrader la prise de commande.
Il reprend à sa prochaine fenêtre. Un verrou en base rend par ailleurs deux synchronisations concurrentes sur le même client impossibles ; si un processus meurt en cours de route, son verrou expire et la synchronisation reprend seule.
Faites défiler la figure →
Redémarrage automatique
L'API est surveillée par un health check ; toute erreur fatale entraîne un redémarrage propre immédiat par la plateforme.
Déploiement sécurisé
Chaque mise en production exécute d'abord ses migrations ; si elles échouent, le déploiement est annulé et la version précédente reste en ligne. Des limites strictes de taille de requête empêchent toute saturation par une requête anormale.
04 · Vos données
Sauvegardées, isolées, réversibles.
Restauration à la seconde près, sur 30 jours glissants
Pas une sauvegarde par nuit : un historique continu. La branche de production est en outre protégée contre toute suppression.
Faites défiler la figure →
Historique continu sur 30 jours
La base conserve un historique continu : l'état des données à n'importe quel instant des 30 derniers jours est restaurable. La branche de production est en outre protégée contre toute suppression.
Réversibilité structurelle
Vos données vivent dans un PostgreSQL standard, sans format propriétaire : un export complet (SQL ou CSV) est possible à tout moment, lisible sans Salesia. La stack (TypeScript, React, PostgreSQL, stockage S3-compatible) est la plus répandue du marché : n'importe quelle équipe technique peut l'auditer ou la reprendre.
Résidence UE de bout en bout
Base et API à Francfort, fichiers en juridiction UE.
Cloisonnement des données par client
Session authentifiée
Source de véritéIdentifiant labo
tenant_idFiltre appliqué à chaque requête SQL
+ restriction au portefeuille du commercialContenu du navigateur
Jamais utilisé comme sourceUn identifiant de laboratoire envoyé par le client est ignoré.
Le cloisonnement est appliqué au niveau de la requête, pas au niveau de l'écran : une erreur d'interface ne peut pas exposer les données d'un autre laboratoire.
Faites défiler la figure →
Contrôles avant mise en production
Pull request
obligatoire
Scan de secrets
historique complet
Audit dépendances
à chaque changement + hebdo
TypeScript strict
bloquant
Production
migrations d'abord
Aucun changement ne part en production sans passer par une pull request et cette chaîne. Les contrats entre l'application mobile et le serveur sont par ailleurs générés et vérifiés automatiquement : toute divergence bloque l'intégration du code.
Faites défiler la figure →
Sécurité
- Sessions httpOnly ; surface d'administration désactivée en production.
- Identifiants d'intégration chiffrés par enveloppe, jamais stockés en clair.
- HTTPS strict (HSTS 2 ans), en-têtes de sécurité sur toutes les réponses.
- Scan de secrets et audit de vulnérabilités à chaque changement ; aucun code ne part en production sans pull request et contrôles automatiques.
Quand quelque chose casse
- Chaque migration de base a son script de retour arrière, versionné avec elle.
- Toute opération destructive sur des données exige un script versionné et un export de sauvegarde préalable : c'est une règle écrite du projet.
- Les post-mortems vivent dans le code, à l'endroit exact où l'incident s'est produit : personne ne peut réintroduire une erreur sans lire pourquoi elle a eu lieu.
- Les contrats entre l'application mobile et le serveur sont générés et vérifiés automatiquement : toute divergence bloque l'intégration du code.
Engagements contractuels
Au-delà de l'architecture : disponibilité, réversibilité et un contact technique nommé, fournis en amont de la signature.
Engagement de disponibilité, plan de réversibilité (export complet de vos données, sans préavis ni frais) pour relecture par vos équipes ou votre conseil. Chaque point de cette page est vérifiable lors d'une session d'audit technique avec vos équipes ou un prestataire de votre choix.