Sécurité

Dernière mise à jour : 1er juillet 2026

Comment GO.LAB fonctionne — le contexte d’abord

GO.LAB n'est pas une plateforme mutualisée à laquelle vous vous inscrivez. Lorsque vous achetez GO.LAB, vous — le propriétaire — déployez votre propre CRM privé, sous votre propre marque (« GO.LAB »), fonctionnant sur des comptes que vous contrôlez auprès de prestataires de premier ordre pour les données, les paiements et l'hébergement. Un déploiement, un propriétaire. Les espaces de vos clients vivent au sein de votre déploiement et nulle part ailleurs. Tout ce qui suit décrit comment ce déploiement protège les données qu'il contient.

Les affirmations en matière de sécurité sont faciles à énoncer et difficiles à vérifier. Cette page explique, en termes précis, comment GO.LAB protège les données qu'il contient — l'architecture, les valeurs par défaut, et, en toute honnêteté, les aspects qui relèvent de votre responsabilité en tant qu'opérateur.

1. Construit sur des services gérés de premier ordre

GO.LAB ne fonctionne pas sur des serveurs gérés manuellement. Le stockage des données, les paiements et l'hébergement sont chacun délégués à des plateformes cloud gérées de premier ordre — les mêmes prestataires d'infrastructure auxquels font confiance les banques, les entreprises de santé et les groupes du Fortune 500.

Cela signifie qu'il n'y a :

• Aucun serveur à corriger. La plateforme d'hébergement gère le système d'exploitation, le réseau et l'environnement d'exécution — les mises à jour de sécurité sont son travail, appliquées en continu.
• Aucune base de données exposée. La couche de données n'a aucun port ouvert, aucune chaîne de connexion à divulguer, et aucun accès réseau direct. Elle n'est accessible que via des chemins authentifiés et contrôlés par permission.
• Jamais de données de carte bancaire dans la plateforme. Les paiements sont traités de bout en bout par un prestataire de paiement certifié (PCI DSS niveau 1). Les numéros de carte ne transitent jamais par le code ou la base de données de GO.LAB.

Les causes les plus courantes de fuites de données réelles — serveurs non corrigés, ports de base de données exposés, identifiants par défaut — ne sont pas des risques que cette architecture se contente d'atténuer. Ce sont des catégories d'erreurs qui ne peuvent pas se produire, car les composants auxquels elles s'appliquent n'existent tout simplement pas ici.

2. Échec en mode fermé par défaut

Une question légitime pour tout logiciel auto-géré : « et si l'opérateur configure mal la plateforme ? » La réponse ici est que la plateforme est conçue pour échouer en mode fermé :

• La base de données refuse tout accès par défaut. Les règles d'accès doivent être explicitement déployées avant que quoi que ce soit puisse être lu — une étape de configuration omise produit une fonctionnalité cassée, pas une fuite de données.
• L'inscription est verrouillée. Le premier compte administrateur est limité à une adresse e-mail préconfigurée, et chaque utilisateur suivant doit être explicitement invité. Il n'y a pas d'inscription libre.
• Les fonctionnalités optionnelles sont livrées désactivées et doivent être activées délibérément par espace par le propriétaire du compte.

Autrement dit : le mode d'échec d'une configuration incomplète ou incorrecte est une application qui ne fonctionne pas encore — pas une application qui fuite.

3. Isolation des espaces, appliquée trois fois

GO.LAB est multi-espaces : chaque espace client possède ses propres contacts, affaires, conversations et enregistrements. L'isolation entre les espaces est appliquée sur trois couches indépendantes, de sorte qu'une défaillance sur l'une d'elles est rattrapée par les autres :

1. Règles de sécurité au niveau de la base de données — chaque lecture et écriture est vérifiée par rapport à l'appartenance à l'espace vérifiée de l'appelant, au niveau de la couche de données elle-même, avant que la moindre donnée ne bouge.
2. Contrôles de permission côté serveur — chaque point d'entrée API revérifie indépendamment l'identité, le rôle et l'appartenance à l'espace de l'appelant à partir de sa session authentifiée. Rien n'est fait confiance depuis le navigateur.
3. Réancrage au niveau de l'enregistrement — chaque fois qu'un enregistrement en référence un autre (le contact d'une affaire, le responsable d'une tâche), la plateforme revérifie que l'enregistrement référencé appartient au même espace avant d'agir. Un identifiant forgé ou erroné ne peut pas atteindre les données d'un autre espace.

4. Rôles et contrôle d’accès

• L'authentification utilise des cookies de session sécurisés et signés, gérés par un service d'identité de niveau entreprise — pas une gestion de mots de passe maison.
• L'accès est basé sur les rôles : les propriétaires de compte, les administrateurs d'espace et les collaborateurs voient et font chacun uniquement ce que leur rôle autorise.
• La disponibilité des fonctionnalités est contrôlée par espace par le propriétaire du compte — un espace ne peut pas activer des capacités qui ne lui ont pas été accordées.
• Le retrait d'un membre prend effet immédiatement : son accès est révoqué, ses sessions sont invalidées, et sa connexion est désactivée s'il ne détient aucun autre accès.

5. Secrets et identifiants

• Le code source ne comporte aucun identifiant intégré. Chaque clé de service est fournie par l'opérateur et stockée dans la configuration chiffrée de la plateforme d'hébergement — jamais dans le code source.
• Les clés API sont stockées uniquement sous forme de hachages cryptographiques à sens unique. La clé complète n'est affichée qu'une seule fois, à sa création. Même une copie complète de la base de données ne peut pas retrouver une clé fonctionnelle.
• Les clés sont révocables et cantonnées : chaque clé API appartient à un seul espace et ne peut jamais voir que les données de cet espace.
• Les secrets sont masqués dans les journaux, afin qu'une ligne de débogage accidentelle ne puisse pas divulguer un identifiant.

6. Des liens publics infalsifiables

Certaines pages sont délibérément publiques — un devis envoyé à un client, une page de réservation, un lien de désabonnement, un lien de paiement. Chacune d'elles est protégée par un jeton signé cryptographiquement :

• Les jetons sont signés (HMAC) et ne peuvent être ni devinés ni falsifiés.
• Seul un hachage à sens unique de chaque jeton est stocké — le lien fonctionnel n'existe que dans l'e-mail du destinataire.
• Un nouvel envoi fait tourner le jeton, ce qui invalide instantanément toute copie antérieure du lien.

7. Intégrations vérifiées

Chaque webhook entrant — événements de paiement, messages entrants, événements d'appel, tâches planifiées — voit sa signature vérifiée avant que le moindre octet ne soit traité. Une requête qui ne porte pas de signature cryptographique valide du service attendu est rejetée. Il n'existe aucun chemin d'écriture non authentifié vers la plateforme. Les webhooks sortants sont également signés, afin que vos propres intégrations puissent vérifier que les événements proviennent bien de votre déploiement.

8. Une IA supervisée par un humain

GO.LAB inclut des assistants IA et des agents conversationnels IA. Ils sont soumis à des limites strictes et structurelles :

• L'assistant ne peut invoquer qu'une liste fixe et auditée de capacités — il n'a aucun accès général à la base de données et aucun moyen de composer ses propres requêtes.
• Aucune action de l'IA ne peut modifier des données sans qu'un humain ne la confirme explicitement au préalable. Les lectures s'exécutent instantanément ; chaque écriture nécessite un clic.
• Chaque capacité de l'IA est ancrée à l'espace de l'appelant lui-même, et une vérification automatisée s'exécute à chaque modification de code pour faire respecter cette règle — c'est un échec de compilation, pas un espoir de relecture de code.
• Chaque action de l'IA — proposée, exécutée ou échouée — est consignée dans un journal d'audit en ajout seul.

9. Un déploiement, un propriétaire — un périmètre de risque réduit

Contrairement à une plateforme SaaS traditionnelle, où les données de milliers d'entreprises se trouvent dans un seul système partagé et où une seule faille expose tout le monde, chaque déploiement GO.LAB est mono-tenant : il ne contient que les données d'une seule entreprise, dans des comptes que cette entreprise contrôle. Vos données ne sont mutualisées avec celles de personne d'autre, ne sont ni exploitées ni revendues, et peuvent être exportées ou supprimées par vous à tout moment.

10. Aucune boîte noire

C'est peut-être la différence la plus importante : GO.LAB n'est pas une boîte noire à laquelle vous devez faire confiance aveuglément. L'opérateur d'un déploiement possède le code source complet. Chaque affirmation de cette page peut être vérifiée en le lisant — ou en le faisant lire par tout professionnel de la sécurité de votre choix. Les plateformes fermées demandent de la confiance ; celle-ci peut être auditée.

11. Ce qui relève de vous (l’honnêteté compte)

Aucune architecture ne supprime toute responsabilité. Si vous exploitez un déploiement, la sécurité de la plateforme suppose que vous allez :

• Protéger les comptes derrière votre déploiement — utiliser des mots de passe forts et uniques, et activer l'authentification à deux facteurs sur vos comptes d'hébergement, de données et de paiement.
• Traiter vos clés de service et votre configuration d'environnement comme des secrets — ne jamais les commiter dans un dépôt public ni les partager dans un chat/capture d'écran.
• Appliquer les mises à jour lorsqu'elles sont publiées, et compléter les étapes de configuration documentées (le vérificateur de configuration intégré contrôle les plus importantes pour vous).

Ce sont les mêmes obligations que vous auriez avec n'importe quel logiciel professionnel — y compris un SaaS, où les mots de passe de votre équipe restent tout autant le maillon faible.

12. Signaler un problème de sécurité

Si vous pensez avoir découvert une vulnérabilité, nous voulons en être informés — merci de la signaler en privé plutôt que publiquement, afin qu'elle puisse être corrigée avant que les détails ne circulent. Discutez avec nous et nous prendrons le relais. Les signalements de bonne foi sont toujours les bienvenus et ne sont jamais sanctionnés.