Accord de traitement des données

1. Objet de cet accord, et quand il s'applique#

Le présent accord de traitement des données (l'« Accord ») s'applique chaque fois que Gheima traite des données personnelles pour votre compte, c'est-à-dire chaque fois que votre application, votre base gérée ou votre stockage objet contient des données relatives à des personnes. Il fait partie des conditions générales et est conclu entre les mêmes parties.

Deux rôles coexistent, et les confondre est la source habituelle des difficultés :

• Pour les données personnelles contenues dans vos charges de travail (vos utilisateurs, vos clients, vos lignes et vos fichiers), vous êtes responsable de traitement et Gheima est sous-traitant. C'est l'objet du présent Accord.
• Pour les données relatives à votre compte Gheima (votre e-mail, vos éléments de facturation, votre piste d'audit), Gheima est responsable de traitement. C'est la politique de confidentialité qui s'applique, pas le présent Accord.

2. Objet, durée, nature et finalité#

3. Traitement sur vos seules instructions#

Nous traitons les données personnelles de vos charges de travail uniquement pour fournir la plateforme, et uniquement selon vos instructions. Votre configuration (la région où vous placez une ressource, ce que vous déployez, ce que vous stockez) constitue cette instruction. Nous vous signalerons toute instruction qui nous paraîtrait contraire au droit applicable à la protection des données, et nous pourrons refuser de l'exécuter.

Si une loi nous impose de traiter ou de divulguer vos données, nous vous en informerons au préalable sauf si cette loi l'interdit. Nous n'accédons pas au contenu de vos bases, compartiments ou conteneurs dans le cours normal de l'exploitation.

4. Confidentialité#

Toute personne chez Gheima ayant accès à la production est tenue à la confidentialité, et l'accès est accordé selon ce dont un rôle a réellement besoin. Les actions d'administration, y compris toute impersonation d'un compte par le support, sont inscrites au journal d'audit.

5. Mesures de sécurité#

Les mesures techniques et organisationnelles que nous appliquons sont, en résumé :

• Chiffrement en transit de tout le trafic externe, avec des certificats émis et renouvelés automatiquement.
• Chiffrement au repos, AES-256-GCM sous une clé dérivée par compte, pour les variables d'environnement, les identifiants de bases gérées, les clés de stockage objet, les jetons Git connectés et les secrets à deux facteurs.
• Isolation des locataires assurée par une colonne sur chaque ressource et un filtrage sur chaque requête, l'accès entre comptes et entre régions étant refusé à la frontière.
• Segmentation réseau par locataire : les bases gérées sont joignables sur un réseau privé et ne publient aucun port sur Internet.
• Builds exécutés dans un démon de construction isolé et sans privilèges, distinct de la gestion du cluster.
• Un journal d'audit en ajout seul, imposé par un déclencheur de base de données, avec minimisation planifiée des champs identifiants.
• Authentification à deux facteurs disponible pour chaque utilisateur et exigible sur les comptes d'équipe.
• Sauvegardes automatisées, stockées chiffrées, avec un exercice de restauration planifié qui restaure réellement : une sauvegarde que personne n'a restaurée n'est qu'une hypothèse.

Nous révisons ces mesures au fil de l'évolution de la plateforme, et nous ne les abaisserons pas en deçà du niveau décrit ici pendant la durée du présent Accord.

6. Sous-traitants ultérieurs#

Vous nous donnez une autorisation générale de recourir à des sous-traitants ultérieurs. La liste en vigueur, avec la finalité et la localisation de chacun, est publiée sur notre page dédiée et fait partie du présent Accord.

Nous publierons tout ajout ou remplacement sur cette page et préviendrons les titulaires de compte par e-mail au moins trente jours avant que le nouveau sous-traitant ne commence à traiter. Si vous vous y opposez pour un motif raisonnable tiré de la protection des données dans ce délai, nous chercherons une solution de remplacement avec vous ; à défaut, vous pourrez résilier le service concerné et nous rembourserons la part non utilisée de la période. Chaque sous-traitant est lié par des obligations au moins aussi protectrices que celles-ci.

7. Assistance face aux demandes des personnes concernées#

Les demandes de vos utilisateurs vous parviennent à vous, pas à nous. Nous n'avons aucune relation avec eux. Lorsque vous avez besoin de notre aide, la plateforme vous donne un accès direct aux données : votre base gérée est à vous d'interroger, vos compartiments sont à vous de lister, et l'export de compte produit vos enregistrements en JSON. Si une demande exige ce que ces moyens n'atteignent pas, écrivez à hello@gheima.ma et nous vous assisterons sans frais.

Vos propres déclarations à la CNDP. En tant que responsable du traitement, vous déclarez vos propres traitements à la CNDP (loi 09-08, art. 12), ainsi que tout transfert de ces données à l'étranger (art. 43 et 44). Sur demande, nous vous fournissons ce que ces formulaires demandent sur l'hébergement : la région et le pays de chaque ressource, nos sous-traitants ultérieurs et leur localisation, et les mesures de sécurité de l'article 5.

Si vous n'êtes pas établi au Maroc. La loi 09-08 (art. 2) impose à un responsable du traitement établi hors du Maroc qui traite des données à l'aide de moyens situés au Maroc, comme une ressource de la région ma-1, de désigner un représentant établi au Maroc. Cette obligation vous incombe ; Gheima ne peut pas être votre représentant.

8. Violations de données personnelles#

Si nous avons connaissance d'une violation affectant des données personnelles que nous traitons pour vous, nous vous en informerons sans retard injustifié et en tout état de cause dans les soixante-douze heures suivant cette connaissance, avec ce que nous savons alors : ce qui s'est passé, quelles données et approximativement combien d'enregistrements sont concernés, les conséquences probables, et ce que nous faisons. Nous continuerons à vous informer à mesure plutôt que d'attendre un tableau complet. La notification à votre autorité de contrôle et à vos utilisateurs, lorsqu'elle est requise, relève de votre décision de responsable de traitement ; nous vous donnerons de quoi la prendre.

9. Suppression et restitution#

Supprimer une ressource dans le tableau de bord déprovisionne la chose réelle, pas seulement son enregistrement : le rôle et la base gérée, l'identité de stockage objet, le conteneur et son volume. Fermer un compte le supprime logiquement et détruit aussitôt les identifiants actifs, le conserve trente jours dans une fenêtre de restauration, puis purge définitivement l'ensemble : bases gérées, compartiments, instances de recherche et de files d'attente, volumes et l'enregistrement du compte lui-même.

Exportez vos données avant de fermer le compte ; passée la fenêtre de grâce, elles ont disparu. Des sauvegardes chiffrées peuvent conserver les données supprimées jusqu'à quatorze jours de plus avant d'expirer, et nous ne prétendrons pas le contraire. À tout moment de la relation, vous pouvez nous demander par écrit de supprimer ou de restituer les données que nous traitons pour vous, et nous le ferons sauf obligation légale de conservation.

10. Audits#

Sur préavis écrit raisonnable, et au plus une fois par an sauf si une autorité de contrôle ou une violation en impose davantage, nous vous fournirons les informations nécessaires pour démontrer le respect du présent Accord, et nous répondrons à un questionnaire de sécurité. Tout audit sur site ou technique est à votre charge, planifié de façon à ne pas affecter les autres clients, et mené par une personne tenue à la confidentialité.

11. Transferts internationaux#

Les transferts vers l'Union européenne reposent sur la liste des États assurant un niveau de protection adéquat établie par la CNDP (loi 09-08, art. 43 ; délibération 236-2015). Les transferts vers les États-Unis (Resend, GitHub, Cloudflare) reposent sur l'article 44 de la loi 09-08 : ils sont nécessaires à l'exécution de notre contrat avec vous. Les transferts vers Google (API Gemini) n'ont lieu que lorsque nos fonctions d'IA optionnelles sont activées, reposent sur le même article et sont déclarés à la CNDP avant l'activation de ces fonctions ; les journaux de build complets de la région ma-1 ne lui sont jamais envoyés. Sur tous les plans, les nouvelles ressources sont placées par défaut dans ma-1 (Casablanca, Maroc). L'article 12 indique exactement où se trouvent les données pour chaque région que nous exploitons.

12. Résidence des données : ce qu'elle couvre exactement#

C'est la section à lire avant de vous fier à l'engagement de résidence, et elle est écrite pour être vérifiable plutôt qu'impressionnante.

L'engagement de résidence est attaché à la région ma-1, à Casablanca, où tous les plans placent leurs nouvelles ressources. Pour une ressource dans ma-1, les éléments suivants restent au Maroc, sur le propre matériel de cette région :

• les conteneurs applicatifs eux-mêmes, épinglés aux nœuds de la région ;
• les bases de données gérées (Postgres, MySQL, MongoDB et Redis) et tout ce qu'elles contiennent ;
• les compartiments de stockage objet et leur contenu ;
• les instantanés et les exports de bases ;
• les entrées de build, les journaux de build et les journaux de déploiement ;
• les journaux et métriques des conteneurs, collectés par la pile de supervision propre à la région ;
• les images de conteneurs, conservées dans le registre propre à la région ;
• les sauvegardes, prises dans la région et copiées vers un second emplacement situé dans le même pays.

Les éléments suivants n'y restent pas aujourd'hui. Ils vivent dans le plan de contrôle, qui sert tous les comptes depuis un seul endroit, à Casablanca (voir ci-dessous) :

• les métadonnées des ressources : noms de vos services, bases, domaines et projets, et les URL des dépôts dont ils sont construits ;
• vos variables d'environnement, stockées chiffrées dans la base de contrôle et déchiffrables à cet endroit ;
• le journal d'audit des actions menées dans le tableau de bord et l'API ;
• les données de facturation : forfaits, factures, compteurs d'usage ;
• les lignes pseudonymisées de statistiques de fréquentation : empreinte de visiteur, chemin, hôte référent, pays, statut, sans IP brute ni agent utilisateur ;
• le processus du tableau de bord lui-même, ce qui signifie que lorsque vous saisissez un secret dans le tableau de bord, il transite en clair par le plan de contrôle à cet instant, avant d'être chiffré et stocké.

Depuis le 21 septembre 2026, le plan de contrôle s'exécute à Casablanca, au Maroc, dans la région ma-1, et sa base de données et ses sauvegardes y sont stockées. L'énoncé exact de ce que la résidence vous apporte est donc : vos données clients au repos restent dans le pays de leur région, et les métadonnées qui les décrivent ainsi que l'interface d'exploitation se trouvent au Maroc. Depuis le 22 septembre 2026, la limite que nous consignions ici est levée : les secrets propres à une seule charge de travail (variables d'environnement des services, mots de passe et chaînes de connexion des bases de données gérées, clés de stockage d'objets) sont chiffrés avec une clé détenue uniquement par la région qui héberge cette charge et par le plan de contrôle au Maroc. Notre infrastructure dans l'Union européenne ne peut plus déchiffrer la configuration d'une charge hébergée ailleurs. Ce qui demeure, dit clairement : les secrets qui appartiennent à votre compte plutôt qu'à une seule charge (groupes de variables partagés, jetons de fournisseurs Git, secrets de notification et de log-drain, clés de signature e-mail, identifiants de recherche et de files) restent sous une clé unique que détiennent les workers de chaque région, car toute région peut exécuter un travail pour votre compte. Nous mettrons cette section à jour, avec un nouveau numéro de version, si cela change.

Deux autres limites, dites franchement. Les charges utiles des travaux de déploiement et de provisionnement transitent par la file centrale ; nous avons vérifié qu'elles ne portent que des identifiants : aucun secret, aucune donnée client. Et une région n'est réputée située dans un pays que sur la foi de la déclaration de notre fournisseur quant à l'emplacement de cette région ; tant que nous ne détenons pas cette déclaration par écrit, la région ne porte aucune promesse de résidence et n'est offerte qu'en aperçu.

13. Ordre de priorité, et responsabilité#

En cas de contradiction entre le présent Accord et les conditions générales sur le traitement des données personnelles, le présent Accord prévaut. Tout le reste des conditions générales, y compris les limitations de responsabilité, s'applique au présent Accord comme s'il y était reproduit.

14. Signature#

Le présent Accord s'applique automatiquement à tous les comptes ; aucune signature n'est nécessaire pour qu'il produise effet. Si votre processus achats exige un exemplaire contresigné, ou la relecture de votre propre modèle, écrivez à hello@gheima.ma.