Aperçu de la sécurité

1. Données en transit

Tout le trafic passe par HTTPS. Les requêtes HTTP sont redirigées et l'en-tête HTTP Strict Transport Security est envoyé, de sorte que les navigateurs refusent de revenir à une connexion non chiffrée après la première visite. Les témoins de session sont marqués Secure; ils ne sont donc jamais transmis par une connexion non chiffrée.

2. Authentification et sessions

• Les mots de passe sont conservés sous forme de hachages adaptatifs salés. Ils ne sont jamais conservés en clair ni sous une forme réversible, et nous ne pouvons pas les récupérer — seulement les réinitialiser.
• Les identifiants de session sont régénérés à chaque connexion, ce qui empêche la fixation de session.
• Les témoins de session sont HttpOnly (illisibles par JavaScript), Secure et SameSite=Lax.
• Les tentatives de connexion échouées répétées depuis une même adresse sont ralenties.
• Les liens de réinitialisation du mot de passe reposent sur 256 bits d'aléa cryptographique, expirent après une heure et ne servent qu'une fois.
• L'authentification à deux facteurs est offerte aux comptes qui l'activent.

3. Isolement des clients

Chaque requête à la base de données est limitée par Organisation, et par utilisateur lorsque l'Organisation est configurée en mode isolé. Les identifiants d'enregistrement fournis par un navigateur sont toujours revérifiés par rapport au compte qui fait la demande avant que l'enregistrement soit lu ou modifié; deviner l'identifiant d'un autre client ne donne donc rien.

Cette règle est appliquée dans un seul chemin de code partagé plutôt que répétée dans chaque point d'accès, ce qui permet de l'auditer.

4. Sécurité applicative

• Injection SQL. Tout accès à la base de données se fait par requêtes paramétrées. Aucune donnée saisie par un utilisateur n'est concaténée dans une requête.
• Script intersites (XSS). Les valeurs sont échappées au moment de l'affichage, et les entrées comme les codes de couleur sont validées sur le serveur selon un format strict.
• Falsification de requête intersites (CSRF). Chaque requête qui modifie des données exige un jeton propre à la session, vérifié par une comparaison à temps constant.
• Politique de sécurité du contenu (Content Security Policy) qui limite les origines autorisées à fournir des scripts et à recevoir des connexions, accompagnée de X-Frame-Options, de X-Content-Type-Options et d'une politique de référent.
• Webhooks. Chaque webhook entrant — Stripe, Shopify, WooCommerce — est vérifié par signature HMAC, au moyen d'une comparaison à temps constant, avant qu'on y donne suite.

5. Données de paiement

Les données de carte sont saisies directement dans la page de paiement hébergée par Stripe et n'atteignent jamais nos serveurs. Fopsis ne reçoit, ne traite ni ne conserve de numéros de carte et n'est donc pas visée par les exigences de stockage de la norme PCI DSS. Nous ne conservons qu'une référence client Stripe et l'état de l'abonnement.

6. Infrastructure et identifiants

L'application et la base de données sont hébergées par Hostinger aux États-Unis. Les identifiants sont conservés dans la configuration de l'environnement du serveur, hors de la racine Web; ils ne sont jamais versés dans le contrôle de source ni exposés au navigateur. L'accès administratif est limité aux personnes qui en ont besoin.

7. Sauvegardes et reprise

La base de données entière est sauvegardée chaque nuit en un seul instantané cohérent. Avant qu'une sauvegarde compte, elle est vérifiée : elle doit se décompresser, être complète et contenir chaque table. Une sauvegarde échouée ou incomplète est consignée et affichée dans nos vérifications de santé plutôt que de passer inaperçue. Les copies quotidiennes sont conservées 14 jours et les copies hebdomadaires 8 semaines, hors du dossier public du site Web, et seul notre compte d'hébergement peut les lire.

Objectif de point de reprise : 24 heures. Objectif de temps de reprise : 24 heures. Voir l'Entente de niveau de service.

8. Surveillance

Des vérifications automatiques ont lieu toutes les 15 minutes et portent sur l'application, la base de données, l'état du schéma, la fraîcheur des sauvegardes, l'âge des synchronisations des intégrations et l'espace disque disponible. Les défaillances nous sont signalées par courriel au moment où elles surviennent, puis de nouveau au rétablissement. L'état actuel est publié à status.php.

9. Examen de sécurité

Le code a fait l'objet d'un examen de sécurité interne structuré portant sur l'authentification, l'autorisation et l'isolement des clients, l'injection et les scripts, la gestion des secrets, la vérification des webhooks et la logique de facturation. Les problèmes relevés ont été corrigés, puis testés de nouveau. Les calculs de prévision ont, par ailleurs, été validés par comparaison avec des implémentations de référence indépendantes.

10. Ce que nous n'avons pas encore

Dit clairement, pour que vous puissiez décider en connaissance de cause :

• Aucune certification SOC 2 ou ISO 27001. Nous n'avons pas été audités par un évaluateur indépendant. Si votre processus d'approvisionnement exige un rapport d'attestation à jour, nous ne satisfaisons pas à cette exigence aujourd'hui.
• Aucun test d'intrusion par un tiers. Jusqu'ici, l'examen de sécurité a été interne.
• Hébergement dans une seule région. Il n'y a aucun serveur de relève actif dans une deuxième région; la reprise après une défaillance totale de l'hébergeur consiste en une restauration à partir d'une sauvegarde dans l'objectif de temps de reprise, et non en un basculement automatique.
• Aucune clé de chiffrement gérée par le client et aucune prise en charge de vos propres clés.
• Aucune authentification unique (SSO) ni SCIM. L'accès se fait par adresse courriel et mot de passe, avec authentification à deux facteurs facultative.
• Aucun programme officiel de primes aux bogues, mais nous accueillons volontiers les signalements (ci-dessous).
• Aucune copie de sauvegarde hors site pour l'instant. Les sauvegardes sont conservées sur l'infrastructure de notre hébergeur, séparément du site Web, mais ne sont pas encore copiées chez un deuxième fournisseur.
• Aucun exercice de restauration planifié pour l'instant. L'intégralité des sauvegardes est vérifiée au moment où elles sont prises; elles ne sont pas encore restaurées dans une base de données de test selon un calendrier.

Ces éléments figurent sur notre feuille de route, dans l'ordre dicté par la demande des clients. Nous préférons vous le dire maintenant plutôt que pendant un examen de sécurité.

11. Signaler une vulnérabilité

Écrivez à support@forecastproai.com avec l'objet « Sécurité ». Donnez assez de détails pour que nous puissions reproduire le problème. Nous accuserons réception dans les deux jours ouvrables et vous tiendrons au courant jusqu'à sa résolution.

Nous n'intenterons pas de poursuites contre les chercheurs qui signalent un problème de bonne foi, évitent les atteintes à la vie privée et la dégradation du service, et nous laissent un délai raisonnable pour corriger avant toute divulgation publique.