top of page

Sécurité des données, confidentialité et RGPD

Version : avril 2026
Statut : document client de synthèse, centré sur l'état actuel du service.

Objet du document

Ce document décrit le fonctionnement actuel de KairoProject sous l'angle de la sécurité des données, de la confidentialité et du traitement des données personnelles. Il ne présente ni feuille de route ni historique d'amélioration : il expose l'état actuel du service et le flux réel des données.

Définitions simples

  • SaaS B2B : logiciel accessible en ligne, fourni par abonnement à des entreprises.

  • Firebase / Firestore : services cloud utilisés pour stocker les données de l'application et faire fonctionner certains traitements serveur.

  • Portfolio : espace de regroupement de plusieurs projets.

  • Organisation : espace d'entreprise partagé entre plusieurs utilisateurs.

  • Role : niveau de droit d'un utilisateur dans un espace. Exemples : owner, admin, member.

  • Owner : responsable principal d'une organisation, avec les droits les plus élevés sur cet espace.

  • Scope : périmetre exact auquel une action ou un modèle s'applique, par exemple un utilisateur seul ou une organisation.

  • Route serveur : point d'entrée technique utilisé par l'application pour traiter une action côté serveur.

  • Admin SDK : outil serveur donnant un accès technique et contrôle à la base de données pour effectuer des operations réservées au back-end.

  • Job asynchrone : traitement lancé en arrière-plan, sans bloquer l'utilisateur pendant son exécution.

  • Bucket de stockage : espace de fichiers utilisé pour stocker temporairement des exports ou imports.

  • Lien signe : lien de téléchargement temporaire, valable pendant une durée limitée.

  • Horodatage : date et heure exactes d'une action.

  • Retention : durée pendant laquelle une trace ou une donnée est conservée avant suppression.

  • DSAR : demande liée aux droits sur les données personnelles, par exemple accès, export ou suppression.

  • OpenAI : service externe utilisé pour certaines fonctions de génération ou d'explication assistées par IA.

  • ML service : service interne de KairoProject dédié aux prédictions et à l’entraînement des modèles.

  • Modèle global : modèle partagé, non réservé à un seul client.

  • Modèle personnalisé : modèle entraîné pour un seul espace client ou une seule organisation.

  • Inference : utilisation d'un modèle pour produire une estimation ou une prédiction.

  • Métadonnées : informations techniques ou descriptives sur une donnée, par exemple une date, un identifiant, une version de modèle ou un statut.

  • Prompt parameters : champs de contexte ou d'instructions associés à un projet pour guider certains traitements IA.

  • ETTC : estimation du travail restant à accomplir sur une tâche.

  • Fever : indicateur visuel de suivi de projet utilisé pour comparer progression et consommation de marge.

Vue d'ensemble

KairoProject est un SaaS B2B de pilotage de projets. Les données applicatives sont traitées dans Firebase / Firestore et via des traitements serveur contrôlés. Les accès sont séparés entre espaces personnels et organisations, avec vérification des droits avant lecture ou écriture côté serveur.

Les opérations sensibles de type export, suppression et journalisation RGPD sont traitées côté serveur et non exposées en accès direct au client web.

Flux principal des données

1. Données de compte et d’accès

  • Les comptes utilisateurs sont gérés via Firebase Authentication.

  • Les données de profil, d'abonnement, de droits et de préférences sont stockées dans Firestore.

  • Chaque utilisateur accède uniquement à son espace personnel ou aux organisations pour lesquelles il dispose d'un droit valide.

  • Les rôles sont séparés entre owner, admin et member.

2. Données métier

  • Les portfolios, projets, tâches, ressources, historiques et paramètres applicatifs sont stockés dans Firestore.

  • Les accès sont contrôlés à deux niveaux :

    • par les règles Firestore ;

    • par des vérifications serveur explicites sur les routes utilisant l'Admin SDK.

  • Les membres désactivés ou les utilisateurs simplement invités ne peuvent pas accéder aux données actives d'une organisation.

3. Export des données

  • Un owner d'organisation peut déclencher un export de ses données.

  • L'export est traité sous forme de job asynchrone.

  • Le résultat est stocké temporairement dans un bucket de stockage.

  • Le lien de téléchargement est généré sous forme de lien signé temporaire.

4. Suppression des données

  • La suppression d'une organisation suit une confirmation explicite par l'owner, puis un traitement asynchrone côté serveur.

  • La suppression d'un compte utilisateur déclenche automatiquement, sans temporisation volontaire, la purge des données actives associées. Cette purge est lancée dès la suppression du compte Firebase Auth et s’exécute ensuite en arrière-plan par Cloud Function.

  • Les opérations RGPD importantes sont journalisées avec horodatage, identifiant du sujet, identifiant de job et date de rétention.

5. Sauvegarde et restauration

  • Les données applicatives sont stockées dans Firestore, service managé de Firebase / Google Cloud.

  • Les mécanismes de sauvegarde et de restauration relèvent donc d'abord des capacités d'exploitation de cette infrastructure managée, et non d'un moteur de sauvegarde propre a KairoProject.

  • KairoProject s'appuie sur cette infrastructure pour la continuité des données, et complète ce socle par ses propres mécanismes d'export, de suppression et de journalisation.

Accès administrateur

Les autres clients n'ont pas accès aux données d'une entreprise. En revanche, l’éditeur conserve un accès administrateur technique encadré à l'infrastructure pour les besoins légitimes de support, maintenance, sécurité et obligations légales. Cet accès doit rester limité, nominatif et journalisé.

Traitement des données par l'IA et le ML

KairoProject distingue deux familles de traitements :

  • les traitements de génération / explication par OpenAI ;

  • les traitements prédictifs et d’entraînement par le service ML interne (ml-service).

Synthèse simple pour le client

Le service ML de KairoProject a un rôle précis : aider à produire des estimations et des prédictions plus utiles pour le pilotage des projets.

Son fonctionnement repose sur deux niveaux :

  • un modele partagé pour fournir une base commune de prédiction ;

  • un modele personnalisé lorsqu'un espace dispose de son propre modèle dédié.

En pratique, cela signifie :

  • les prédictions ne sont pas fabriquées de manière opaque directement dans le navigateur ;

  • elles passent par des traitements serveur contrôlés ;

  • un modèle personnalisé reste rattaché à l'espace concerné et n'est pas réutilisé pour un autre client ;

  • le modèle global sert de référence commune, tandis que le modèle personnalisé permet d'aller vers une meilleure adéquation au contexte du client.

Autrement dit, ce service est structuré pour être à la fois utile au client, encadré techniquement, et compatible avec une logique de confidentialité par espace.

1. Cas où OpenAI est utilisé

OpenAI est appelé côté serveur pour certaines fonctions d'assistance, de génération ou d'explication.

Selon la fonctionnalité utilisée, les données suivantes peuvent être transmises à OpenAI :

  • un brief saisi par l'utilisateur pour générer un projet ou un aperçu de plan ;

  • des informations de contexte comme le domaine, les contraintes, la taille d’équipe ou l'objectif du projet ;

  • des noms de tâches ou des éléments de structure nécessaires à la génération ;

  • pour l'analyse de retards, un résumé structuré du projet, des problèmes signalés, un historique d'utilisation des ressources et un bloc de prédiction déjà calculé par le moteur ML.

Les appels OpenAI ne sont pas faits directement depuis le navigateur du client vers le fournisseur ; ils passent par les routes serveur de KairoProject, avec contrôles d’entrée, limitation de débit et filtrage des modeles autorises.

2. Ce qui n'est pas envoyé à OpenAI dans tous les cas

  • L'assistant de base documentaire interne (knowledge search / knowledge chat) travaille sur la documentation produit indexée par KairoProject et non sur les données métier d'une entreprise.

  • L’accès à un scope utilisateur ou organisation est vérifié côté serveur avant tout usage de contexte lie a un espace donné.

  • Les modèles OpenAI utilisables sont restreints par allowlist côté serveur.

3. Persistance des traitements OpenAI

  • Les routes applicatives renvoient la réponse générée au client.

  • Le code serveur de ces routes n’écrit pas automatiquement l'invite OpenAI complet dans un journal métier dédié.

  • Si un utilisateur réinjecte ensuite le résultat dans ses données de projet, cette persistance relève alors du fonctionnement normal de l'application.

4. Cas où le service ML interne est utilisé

KairoProject utilise également un service interne dédié aux prédictions et à l’entraînement de modèles.

Ce service reçoit selon les cas :

  • des variables structurelles de prédiction, par exemple nombre de tâches actives, tâches bloquées, charge cumulée, progression, consommation du buffer, horizon de prédiction et autres indicateurs quantifiés ;

  • des exportes reconstruits d'un espace donné pour entraîner un modèle personnalisé ;

  • des fichiers d'import métier fournis par le client pour enrichir un entraînement personnalisé ;

  • pour le modèle global, les exportes et importes des espaces éligibles à cette contribution.

Le service ML n'est pas sélectionné librement depuis le client : les appels passent par le serveur de KairoProject, avec vérification des droits et sélection explicite du modèle applicable.

5. Modèle global et modèle maison

KairoProject distingue :

  • un modèle global, partagé ;

  • un modèle personnalisé (custom), isolé par scope.

Le modèle personnalisé est entraîné uniquement sur les données du scope actif :

  • users/{uid} pour un espace personnel ;

  • organizations/{orgId} pour une organisation.

Un modèle personnalisé n'est actif que si les métadonnées stockées correspondent exactement au scope actif. Cela évite qu'un client utilise par erreur le modèle d'un autre client.

6. Ce que signifie ici l'anonymisation pour le modèle global

Dans le produit, le terme « modèle global" signifie qu'il s'agit d'un modèle partagé, non rattaché à un client unique au moment de l'inference. Les métadonnées conservées côté application pour ce modèle sont regroupées : versions, volumes de lignes, nombres de projets, nombres de scopes contributeurs.

En revanche, l’entraînement du modèle global repose sur les exportes courants des espaces contributeurs et sur leurs importes actifs lorsqu'ils sont autorises. Il ne faut donc pas comprendre "anonymisation" comme la promesse que toute donnée source serait préalablement transformée en un jeu totalement irréversiblement anonyme avant l’entraînement. Le sens actuel est le suivant :

  • le modèle résultant est partagé ;

  • La contribution au modèle global est contrôlée par une activation explicite de l'administrateur de l'espace concerné (globalContributionOptIn) ;

  • Les métadonnées exposées dans l'application pour ce modèle sont regroupées ;

  • Le modèle personnalisé, lui, reste isolé par client ou espace.

7. Contribution au modèle global

  • Les données internes d'un scope peuvent contribuer au modèle global selon la politique associée à cet espace.

  • Les données importées par un client ne contribuent au modèle global que si la contribution globale a ete activee explicitement par l'administrateur de l'espace concerne.

  • La contribution est réévaluée à chaque cycle de réentraînement global.

8. Quelles données peuvent alimenter le modèle global ?

Lorsqu'un espace contribue au modèle global, le service d’entraînement interne peut exploiter deux familles de données :

  • les exportés reconstruits depuis les portfolios et projets de cet espace ;

  • les fichiers d'import d’entraînement encore actifs pour cet espace, lorsqu'ils sont autorises a contribuer.

Dans l’état actuel du produit, cela peut inclure notamment :

  • des identifiants techniques de scope et de projet transmis dans les exportés internes ;

  • les identifiants externes des portfolios, projets, tâches, ressources, équipes et calendriers ;

  • les noms de portfolios, projets, tâches, ressources, équipes et calendriers ;

  • les descriptions de portfolio et de projet ;

  • les paramètres de projet utiles au moteur, y compris certains promptParameters s'ils existent sur le projet ;

  • les dates, statuts, durées, ETTC, priorités, catégories, chaînes de dépendance, ressources associées, historiques ETTC et points Fever ;

  • les fichiers d'import métier versés par le client pour l’entraînement personnalisé ou global selon l'option activée.

Autrement dit, la contribution au modèle global ne se limite pas aujourd'hui à des statistiques purement numériques déjà anonymisées. Le service reconstruit d'abord des exportés applicatifs puis dérive ensuite les jeux de données d’entraînement nécessaires.

9. Quelles données ne sont pas envoyées dans ce flux de modèle global ?

Dans l’état actuel du produit, le flux d’entraînement du modèle global n'est pas alimenté par les catégories suivantes :

  • les mots de passe ou secrets d'authentification ;

  • les données de facturation Stripe ;

  • les journaux RGPD, journaux de suppression, preuves DSAR et journaux de supervision ;

  • les contenus de base documentaire interne utilisés pour l'assistant de connaissance ;

  • les données de compte de type email, rôle global, paramètres de session ou claims d'authentification, hors identifiants techniques nécessaires à l'export interne.

10. Exemple concret

Exemple simplifié :

  • si un client active la contribution globale et crée un projet nommé Migration ERP Groupe X, avec une description contenant des termes métier sensibles, des noms de tâches explicites et un import CSV contenant des libellés de tâches et des ressources, ces éléments peuvent faire partie du flux interne d’entraînement vers le service ML ;

  • en revanche, un autre client n'obtient pas accès à ces données en clair dans l'application : elles ne sont pas exposées comme un export partagé ou un écran commun ; elles contribuent uniquement au modèle partagé entraîné en interne.

Pour un client qui souhaite limiter au maximum ce qui peut entrer dans ce flux, la recommandation la plus prudente est :

  • ne pas activer la contribution au modèle global lorsque cette activation n'est pas souhaitée pour l'espace concerné ;

  • éviter de saisir dans les noms, descriptions, libellés de tâches ou fichiers d'import des informations inutilement nominatives, confidentielles ou stratégiques si elles ne sont pas nécessaires au pilotage du projet.

Règles automatiques actuellement appliquées

​

​

​

​

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

​

​

​

​

​

​

​

​

​

​

​

​

​

Rétention et persistance

  • Les données actives du service restent stockées dans les collections applicatives tant que le compte, l'organisation ou les contenus associés existent.

  • La sauvegarde et la restauration de l'infrastructure de base de données reposent sur les mécanismes operes sur Firebase / Google Cloud.

  • Les journaux DSAR sont conservés 12 mois.

  • Les journaux de suppression d'organisation sont conservés 12 mois.

  • Les jobs techniques de suppression d'organisation sont conservés 90 jours.

  • Les jobs d'export d'organisation sont conservés 7 jours.

  • Les liens signés de téléchargement d'export expirent après 24 heures.

Ce que cela signifie pour un client

Aujourd'hui, KairoProject peut être présenté comme un service :

  • avec une séparation sérieuse des données ;

  • avec des accès encadrés par utilisateur, organisation et rôle ;

  • avec des mécanismes concrets d'export et d'effacement ;

  • avec une traçabilité technique des opérations sensibles ;

  • avec un fonctionnement IA et ML passé par le serveur et non librement exposé ;

  • avec un cadre RGPD déjà structuré pour une revue client ou un pré-audit.

Documents d'appui

  • Politique de confidentialite

  • Conditions generales d'utilisation

  • Mentions legales

  • Politique cookies

  • Documentation RGPD et securite plus detaillee communiquee sur demande, selon le contexte client ou contractuel

bottom of page