Contrat de sous-traitance — article 28 du RGPD

Identifiant de version : dpa-2026-09-09-v1.14. Votre signature ne vaut que pour la version qu'elle nomme : si ce contrat change, un nouvel identifiant paraît et votre signature vous est redemandée. (Métadonnée technique — voir apps/web/src/lib/dpa.ts, seule source du code pour cette chaîne ; à incrémenter à toute modification du texte, comme la CGU.)

Annexe au contrat de service BALYS. Ce document n'est pas une politique interne : il est destiné à être signé par le client. Il est exigé par l'article 28.3 du règlement (UE) 2016/679, qui impose que « le traitement par un sous-traitant [soit] régi par un contrat ou un autre acte juridique […] qui lie le sous-traitant à l'égard du responsable du traitement ». Sans lui, le client est en infraction, pas seulement nous. C'est lui qui doit démontrer qu'il n'a fait appel qu'à un sous-traitant présentant des garanties suffisantes (article 28.1). Un prospect dont le service juridique réclamera ce document avant de déposer le premier contrat a raison de le réclamer, et ne pas l'avoir sous la main coûterait la vente.

Version 1.14 — 9 septembre 2026

Avant de le signer — deux notes qui ne font pas partie du contrat

1. Ce document n'est pas un avis juridique et ne se présente pas comme validé par un professionnel du droit. Il a été rédigé en lisant le texte du règlement — article 28, relu mot pour mot sur le texte français publié au Journal officiel de l'Union européenne, JO L 119 du 4.5.2016, p. 1 (EUR-Lex, CELEX 32016R0679) — et en confrontant chaque engagement au code du produit. Il est prêt pour la relecture d'un juriste, pas à sa place. La réserve porte sur la qualification juridique : les faits techniques décrits aux annexes ont été vérifiés dans le dépôt.

Correction de la version 1.9, et il vaut mieux l'écrire que de la faire en silence : jusqu'à la version 1.8, ce paragraphe citait le règlement d'après le document ST 5419/16 du Conseil de l'Union européenne, présenté comme « la version adoptée du règlement », en justifiant ce détour par un refus d'accès automatisé d'EUR-Lex. Les deux points étaient faux. ST 5419/16 est la position du Conseil en première lecture du 6 avril 2016 — un texte de compromis, non l'acte promulgué — et EUR-Lex rend le texte français sans difficulté. Le registre des traitements avait corrigé cette même citation ; le présent contrat s'était appuyé sur la source écartée. Les citations de l'article 28 faites ici ont été confrontées au texte du Journal officiel.

2. Trois conditions doivent être levées avant toute signature. Elles sont détaillées au registre des traitements, chapitre « Écarts constatés », communiqué au Client dans les conditions de l'article 13, et chacune porte sur une obligation que ce contrat fait naître :

É-3 (rotation des sauvegardes hors site), É-7 (cloisonnement contourné depuis l'application) et É-5 (secret dans l'historique du dépôt) ont été levées et ne figurent plus parmi les conditions de signature : voir l'article 11 et l'annexe 2, mis à jour en conséquence.

Sur É-5, la précision compte, et le mot « levée » ne doit pas dire plus que ce qui a été fait : l'historique du dépôt a été purgé et vérifié le 4 septembre 2026 — plus aucune occurrence du secret, marqueurs de remplacement en place, aucun dépôt distant n'ayant jamais existé —, et la rotation du mot de passe en base a été vérifiée : l'ancien secret est refusé par la base. Reste, hors de ce dépôt et donc hors de la phrase de l'annexe 2 qui portait la réserve : deux archives de l'historique d'avant-purge conservées dans le répertoire de l'exploitant, dont une contient encore les secrets — morts pour cette base, mais conservés en clair. Le point est déclaré au registre (É-13). Il ne porte plus sur une affirmation de ce contrat, mais il n'a pas disparu.

Signer ce document avant de les avoir levées reviendrait à s'engager sur ce qui n'est pas fait, ce qui est plus grave que de ne pas s'être engagé.

Ces conditions sont des conditions de signature, pas des réserves opposables au Client : une fois levées, ce chapitre disparaît du document remis.

Entre les parties

Le responsable du traitement, ci-après « le Client » :

Le sous-traitant, ci-après « BALYS » :

Article 1 — Objet

BALYS met à la disposition du Client un service en ligne qui surveille les échéances de ses contrats fournisseurs : dépôt de documents, extraction assistée des dates et des durées de préavis, calcul des échéances, et envoi d'alertes avant qu'un délai de dénonciation n'expire.

Pour rendre ce service, BALYS traite des données à caractère personnel pour le compte du Client et sur ses seules instructions. Le Client demeure le responsable de ces traitements au sens de l'article 4.7 du RGPD ; BALYS agit en qualité de sous-traitant au sens de l'article 4.8.

BALYS ne détermine ni les finalités ni les moyens essentiels du traitement — quelles données sont déposées, pendant combien de temps, qui y accède. S'il venait à le faire, il serait considéré comme responsable du traitement pour ce qui concerne ce traitement (article 28.10), ce que le présent contrat a précisément pour objet d'éviter.

Le présent contrat définit les conditions de cette sous-traitance. Il prévaut sur toute stipulation contraire des conditions générales. Il est établi sous forme écrite, y compris électronique, conformément à l'article 28.9.

Le « contrat de service » désigne, pendant la bêta, les conditions générales d'utilisation de BALYS, dans leur version identifiée cgu-2026-09-04-v1.0 — le seul contrat de service existant à la date de cette version, la bêta étant gratuite et aucune condition générale de vente n'étant publiée. Ajouté en version 1.8 : le terme était employé à trois endroits du présent contrat sans être rattaché à aucun document, alors que les conditions générales, elles, nomment le présent contrat par son chemin.

Article 2 — Ce qui est traité

Le détail figure à l'annexe 1, qui fait partie intégrante du contrat et répond aux mentions exigées par l'article 28.3, premier alinéa : objet, durée, nature et finalité du traitement, type de données à caractère personnel et catégories de personnes concernées. Les obligations et les droits du Client, qui relèvent de la même énumération, font l'objet de l'article 5.

Article 3 — Durée

Le présent contrat prend effet à la date de sa signature et demeure en vigueur tant que BALYS traite des données pour le compte du Client, c'est-à-dire jusqu'au terme de la prestation, augmenté du délai de restitution et d'effacement prévu à l'article 11.

Les obligations de confidentialité (article 6) et de sécurité (article 7) lui survivent sans limitation de durée.

Article 4 — Instructions documentées

BALYS ne traite les données que sur instruction documentée du Client (article 28.3.a). Constituent des instructions documentées :

1. le présent contrat et ses annexes ;
2. le contrat de service et sa documentation ;
3. l'usage que le Client fait lui-même de l'interface — déposer un document, corriger une date extraite, désigner un destinataire d'alerte, supprimer une pièce : chacun de ces gestes est une instruction, et il est horodaté dans le journal d'audit de son espace. Une conséquence à connaître, et qui joue contre BALYS : ce journal est effacé avec l'espace (article 11). Après la fermeture, BALYS ne dispose donc plus d'aucune preuve des instructions reçues — c'est le prix de l'effacement complet, et il est assumé plutôt que corrigé par une conservation que rien ne justifierait envers le Client ;
4. toute demande écrite adressée à contact@myracl.com par une personne habilitée par le Client.

BALYS n'utilise les données du Client pour aucune finalité commerciale propre. En particulier, et sans que cette liste soit limitative : ni prospection, ni revente, ni cession, ni statistiques commerciales, ni constitution d'un jeu de données, ni entraînement ni amélioration d'un quelconque modèle d'intelligence artificielle.

Une exception existe, et elle est nommée plutôt que sous-entendue : la sécurité du service. BALYS lit le journal d'audit de l'espace du Client pour y repérer les gestes qui trahiraient un accès illégitime — export complet de l'espace, demande de fermeture, désactivation de la double authentification, connexion depuis un réseau jamais vu ou précédée d'une rafale d'échecs — ainsi que, une fois par jour, des volumes de lecture et de suppression et des heures de connexion inhabituelles. Cette finalité-là est celle de BALYS, décidée par lui, et il en est donc responsable du traitement au sens de l'article 28.10 pour cette lecture précise ; elle est déclarée à son registre (T8) et décrite à la politique de confidentialité, que le Client peut opposer. Elle n'est pas une facilité de rédaction : elle est la condition de l'article 12 ci-dessous — sans détection, il n'y a pas de notification de violation.

Et ce dispositif est EN MARCHE depuis le 5 septembre 2026. Corrigé en version 1.11 : les versions 1.9 et 1.10 le déclaraient à l'arrêt, ce qui était vrai quand elles ont été écrites et ne l'est plus. Ses deux tâches automatiques — le détecteur, toutes les deux minutes, et le récapitulatif quotidien — ont été remises en service le 5 septembre 2026 à 08 h 37 (UTC), <!-- état-unité: balys-securite-quotidien.timer --> après la correction du code qui avait motivé leur arrêt du 4 septembre au soir. Aucun signal n'a été produit depuis. La conséquence pour le Client est celle-ci, et elle joue en sa faveur : l'engagement de notification sous vingt-quatre heures de l'article 12 court à compter de la connaissance d'une violation, et il existe désormais un moyen automatique de porter une intrusion à cette connaissance — là où, jusqu'à ce matin, seule une lecture à la main du journal pouvait le faire. La politique de confidentialité publiée le dit dans les mêmes termes. Un état de service n'est pas un fait de code : il se relève à chaque revue, il ne se recopie pas d'une version à la suivante. Une SECONDE lecture relève de la même exception, et elle est déclarée ici plutôt que laissée à l'annexe. BALYS surveille aussi l'intégrité de son propre périmètre technique — stockage, sauvegardes, code, tâches planifiées, base de données. Sept détecteurs y concourent ; deux d'entre eux lisent le journal d'audit de l'espace du Client : les mises en quarantaine prononcées par l'antivirus, parce qu'un dépôt refusé signifie le plus souvent que le poste du Client est infecté et qu'il faut le lui dire, et les rafales de dépôts, de consultations ou de suppressions dans une même heure, parce que c'est ainsi que se voient une aspiration de parc documentaire et un effacement en masse. Cette finalité-là est aussi celle de BALYS, décidée par lui, et il en est responsable du traitement au sens de l'article 28.10 pour ces deux lectures ; elle est déclarée à son registre (T10) et le flux sortant qui en découle est le flux 8 de l'article 9. Ce dispositif est en marche depuis le 9 septembre 2026** ; à la date de la version précédente, le <!-- état-unité: balys-integrite.timer --> code existait et l'unité qui le fait tourner n'était ni installée ni démarrée.

Ce que BALYS s'interdit malgré cette exception : y chercher autre chose que des signaux de sécurité, en tirer une appréciation des personnes, et faire sortir de l'infrastructure quoi que ce soit qui les nomme (voir l'annexe 3, « Ce qui n'est pas un sous-traitant ultérieur »).

Si une instruction du Client paraît à BALYS constituer une violation du RGPD ou d'une autre disposition relative à la protection des données, BALYS l'en informe immédiatement et peut suspendre son exécution jusqu'à confirmation écrite (article 28.3, dernier alinéa).

BALYS ne transfère aucune donnée vers un pays tiers ou une organisation internationale en dehors de ce que prévoit l'article 9, sauf instruction écrite du Client ou obligation résultant du droit de l'Union ou d'un État membre — auquel cas BALYS en informe le Client avant le traitement, sauf si ce droit l'interdit pour des motifs importants d'intérêt public (article 28.3.a).

La même réserve vaut pour tout traitement, et pas seulement pour les transferts : si le droit de l'Union ou d'un État membre auquel BALYS est soumis lui impose de traiter des données du Client autrement que sur son instruction, BALYS l'en informe avant le traitement, sauf interdiction faite par ce droit pour des motifs importants d'intérêt public. L'article 28.3.a pose cette réserve pour l'ensemble du paragraphe ; les versions précédentes de ce contrat ne l'énonçaient que pour les transferts.

Demandes d'une autorité publique. Si une autorité administrative ou judiciaire, française ou étrangère, réclame à BALYS des données du Client : BALYS en informe le Client sans délai, sauf lorsque la loi le lui interdit ; il ne remet que ce que la demande exige strictement ; il conteste, par les voies disponibles, une demande qui lui paraît illégale ou disproportionnée ; et il tient à la disposition du Client la trace de ce qui a été remis. Cette stipulation n'est pas exigée par l'article 28.3, et ne figure pas dans les clauses types de la décision 2021/915 — c'est la clause 15 des clauses types « transferts » (2021/914) qui la porte. Elle est écrite ici parce que c'est la question que pose tout service juridique, et que ne rien prévoir serait une réponse en soi.

Article 5 — Obligations et droits du Client

L'article 28.3, premier alinéa, impose que le contrat définisse « les obligations et les droits du responsable du traitement ». Cet article y répond ; il n'est pas une formalité, car plusieurs de ces obligations conditionnent la licéité de ce que BALYS exécute ensuite.

Le Client s'oblige à :

1. disposer d'une base légale pour les traitements qu'il confie à BALYS, et avoir informé les personnes concernées dans les conditions des articles 12 à 14 — y compris du recours à un sous-traitant ;
2. ne donner que des instructions licites, et répondre de celles qu'il donne ;
3. ne déposer aucun document contenant des catégories particulières de données au sens de l'article 9, ni de données relatives à des condamnations pénales au sens de l'article 10. Le service est conçu pour des contrats fournisseurs ; il ne recherche pas ces données et n'en tire aucune conclusion, mais il ne peut pas empêcher qu'on les y dépose.

Et si c'est arrivé ? L'interdiction ne suffit pas : un contrat de prévoyance peut mentionner l'état de santé d'un dirigeant, et la question se posera. Ce qui est prévu, à défaut de pouvoir l'empêcher : si BALYS constate la présence de telles données, il en informe le Client sans délai et n'exécute sur elles aucun traitement au-delà de ce qui a déjà eu lieu ; le Client peut supprimer le document par l'interface, ce qui retire la ligne, ses extractions, ses événements et l'objet chiffré du stockage ; et il peut, s'il le préfère, demander la suppression à BALYS dans les conditions de l'article 10.1. Les garanties générales de l'annexe 2 — chiffrement des documents, cloisonnement, accès d'administration limité — s'appliquent à ces données comme aux autres, mais aucune garantie spécifique* n'est offerte au sens de la clause 7.5 des clauses types de la décision 2021/915 : le service n'est pas conçu pour en recevoir, et il vaut mieux l'écrire que de promettre un traitement particulier qui n'existe pas ;

4. désigner des adresses d'alerte exactes, dont il a la maîtrise ou l'accord du titulaire. Une adresse livrable n'est pas une adresse qu'on possède, et une erreur de saisie divulguerait à un tiers réel un nom de fournisseur, un montant et une échéance. Le service exige pour cette raison une confirmation de l'adresse avant de lui envoyer quoi que ce soit ;
5. gérer les accès à son espace : n'inviter que des personnes habilitées, retirer les accès devenus inutiles, et tenir à jour les rôles.

*À la date de signature, cette obligation n'a pas encore d'objet. Le logiciel ne permet pas d'inviter d'autres utilisateurs : l'espace du Client ne comporte que le compte de son propriétaire, et les rôles inscrits dans la base n'ouvrent pas de droits différenciés (conditions générales d'utilisation, articles 2.3 et 3.14). Les stipulations du présent contrat relatives aux invitations, aux rôles et aux utilisateurs de l'espace — ici, à l'article 9, à l'article 10.1 et à l'annexe 1 — prennent effet à l'ouverture de cette fonction. Elles sont écrites d'avance plutôt que ajoutées après coup, mais il serait trompeur de laisser croire qu'elles décrivent le produit livré* ;

6. répondre lui-même aux demandes des personnes concernées, BALYS lui prêtant assistance dans les conditions de l'article 10 ;
7. informer BALYS sans délai de tout élément affectant la licéité des traitements confiés, notamment l'exercice d'un droit d'opposition ou d'effacement qui appelle une action dans son espace.

Le Client dispose des droits suivants, qui sont autant d'obligations pour BALYS : donner des instructions (article 4), s'opposer à un nouveau sous-traitant ultérieur et résilier sans frais (article 8), obtenir assistance (article 10), choisir entre la restitution et l'effacement (article 11), être notifié de toute violation (article 12), obtenir le registre et les informations nécessaires (article 13), faire réaliser un audit (article 14), et — c'est le droit qui donne une conséquence à tous les autres — suspendre le traitement puis résilier en cas de manquement de BALYS (article 16).

Article 6 — Confidentialité

BALYS veille à ce que les personnes autorisées à traiter les données du Client s'engagent à en respecter la confidentialité (article 28.3.b).

À la date de signature, une seule personne physique dispose d'un accès d'administration : Guillaume Dhainaut, tenu à la confidentialité à raison même de sa qualité d'exploitant. Toute personne qui viendrait à disposer d'un tel accès sera préalablement liée par un engagement de confidentialité écrit.

Cet accès d'administration est technique — exploitation, sauvegarde, correction d'incident. Il ne comporte aucune consultation du contenu des documents du Client, sauf dans trois cas, et seulement dans la mesure strictement nécessaire :

1. le Client le demande explicitement ;
2. la résolution d'un incident qu'il a signalé l'exige ;
3. BALYS détecte lui-même un incident de sécurité et doit en établir la nature et l'étendue pour satisfaire à l'article 12 du présent contrat.

Le troisième cas mérite d'être écrit plutôt que sous-entendu : sans lui, BALYS serait tenu de notifier sous vingt-quatre heures une violation qu'il lui serait contractuellement interdit d'examiner. Toute consultation à ce titre est inscrite à la chronologie de l'incident et communiquée au Client avec la notification — ce qui a été regardé, et pourquoi.

Article 7 — Sécurité

BALYS met en œuvre les mesures techniques et organisationnelles appropriées exigées par l'article 32, comme le lui impose l'article 28.3.c. Elles sont décrites à l'annexe 2, qui ne mentionne que des mesures en place à la date de rédaction. La réserve É-5 qui figurait ici a été retirée en version 1.8 : elle portait sur l'historique du dépôt de code, non sur une mesure de l'annexe 2, et elle est aujourd'hui levée pour ce qu'elle visait — voir l'annexe 2, « Organisation », et le registre.

Ces mesures peuvent évoluer avec l'état des connaissances. Elles ne peuvent pas être abaissées : toute modification maintient un niveau de protection au moins équivalent.

Article 8 — Sous-traitants ultérieurs

Le Client donne à BALYS une autorisation générale écrite de recourir à d'autres sous-traitants, au sens de l'article 28.2. La liste de ceux qui sont autorisés à la date de signature figure à l'annexe 3.

En cas d'ajout ou de remplacement, BALYS en informe le Client par écrit au moins trente (30) jours à l'avance. Le Client dispose de ce délai pour émettre des objections motivées. En cas d'objection que les parties ne parviennent pas à lever, le Client peut résilier le contrat de service sans frais ni pénalité, et obtient le remboursement au prorata des sommes versées d'avance.

BALYS impose à tout sous-traitant ultérieur les mêmes obligations de protection des données que celles du présent contrat et demeure pleinement responsable devant le Client de l'exécution par celui-ci de ses obligations (article 28.4).

BALYS communique au Client, à sa demande, une copie de l'accord de traitement conclu avec tout sous-traitant ultérieur, ainsi que de ses modifications ultérieures, expurgée des seules stipulations commerciales ou confidentielles qui n'intéressent pas la protection des données. Sans cette phrase, l'article 28.4 n'est vérifiable qu'en croyant BALYS sur parole ; c'est la clause 7.7 des clauses types de la décision 2021/915 qui la porte, dans les mêmes termes.

Article 9 — Transferts hors de l'Union européenne

Les serveurs qui exécutent le service et hébergent les documents sont situés en France, chez un hébergeur établi dans l'Union européenne. Cette localisation est celle que déclare l'hébergeur et que reflète l'enregistrement des adresses du serveur ; elle sera confirmée par une attestation écrite du prestataire, dont l'obtention figure au registre des traitements (É-11). Le registre et le présent contrat portent la même réserve : aucun des deux documents n'affirme plus que l'autre.

Huit flux quittent nos systèmes vers un prestataire situé hors de l'Union européenne, dont six vers les États-Unis, et les six fonctionnent aujourd'hui — le dernier, la veille d'intégrité, est en service depuis le 9 septembre 2026. <!-- état-unité: balys-integrite.timer --> Chaque version de cet inventaire en a découvert un de plus que la précédente, et toujours pour la même raison — l'inventaire était écrit de mémoire plutôt que relevé sur les canaux qui existent. La version 1.7 en annonçait deux, « tous deux à destination de la Suisse », et se démentait elle-même trois paragraphes plus bas. La version 1.8 en a recensé quatre et a oublié les échecs de tâche planifiée. La version 1.9 en a recensé cinq et a oublié le rapport de fréquentation du site public, qui part chaque heure dans un troisième salon du même prestataire américain. La version 1.10 en a recensé six et s'est trompée sur le décompte de ceux qui marchent : elle écrivait « deux de ces quatre fonctionnent » quand son propre tableau, trois lignes plus bas, en marquait trois « Oui » — le réseau privé n'avait pas été compté. La version 1.11 a écrit la bonne règle et ne l'a pas tenue : sa phrase disait « quatre de ces cinq fonctionnent — le cinquième n'est pas encore installé », ce qui était exact le 5 septembre et faux dès le 7, jour où le salon des demandes d'accès a été mis en service. La ligne 7 du tableau a bien été reprise ce jour-là ; la phrase qui la résume ne l'a pas été — alors que c'est précisément elle qui promet de se recompter sur lui. Le tableau ci-dessous est relevé sur les canaux d'envoi eux-mêmes, et la phrase qui le résume se recompte SUR LUI ; celui qui ajoute un flux l'ajoute ici et refait les deux.

Les flux 4, 5, 6 et 7 partagent un compte de robot et un prestataire, pas un salon. La version 1.9 écrivait qu'ils partageaient « un canal » : c'est faux, et la nuance n'est pas cosmétique — quatre salons distincts, c'est quatre audiences possibles. Le quatrième est le dispositif de détection d'intrusion, en marche depuis le 5 septembre 2026 et sans signal produit à <!-- état-unité: balys-veille-intrusion.timer --> ce jour. Le cinquième est la sonnette qui prévient l'exploitant qu'une tâche de nuit — sauvegarde, vérification de restauration, calcul des échéances — s'est arrêtée en erreur. Le sixième est le rapport de fréquentation du site vitrine, publié chaque heure. Le septième est le salon où BALYS décide d'ouvrir ou non un accès à quelqu'un qui l'a demandé, et il est en service depuis le 7 septembre 2026. <!-- état-unité: balys-acces-beta.service --> Le flux 8 ne partage pas même le compte de robot, et c'est le seul du lot dans ce cas. Son jeton lui est propre, il ne peut écrire que dans son salon, et il se révoque seul — sans faire taire du même geste les alertes de sauvegarde, celles de sécurité ni le circuit des demandes d'accès. La raison n'est pas une commodité : un canal qui surveille l'intégrité doit pouvoir être coupé le jour où c'est lui qu'on soupçonne, et un dispositif de surveillance ne doit pas détenir la clé de tout ce qu'il surveille. Pour le Client, cela change ce qu'une fuite de jeton emporterait : les quatre premiers salons tombent ensemble, le cinquième tombe seul.

Aucun des cinq n'emporte de donnée du Client — au sens de ce contrat, c'est-à-dire rien de ce que le Client a écrit, déposé ou saisi. Le septième, seul à porter des données identifiantes, ne porte que celles d'une personne qui n'a pas encore d'espace, donc jamais des données confiées à BALYS en sous-traitance. Les flux 4 et 8, eux, emportent des identifiants techniques qui désignent un espace sans le nommer : le raisonnement qui les distingue d'une donnée du Client, et ses limites, sont écrits à l'annexe 3 plutôt qu'affirmés ici.

Le fondement du transfert vers ce prestataire américain, pour le seul flux qui en appelle un. Les flux 4, 5, 6 et 8 n'emportent aucune donnée à caractère personnel — c'est le raisonnement, avec ses limites, exposé à l'annexe 3. Le flux 7, lui, en emporte : il est fondé sur l'article 45 et la décision d'exécution (UE) 2023/1795 de la Commission du 10 juillet 2023 (JO L 231 du 20.9.2023, p. 118), dont l'article premier ne reconnaît un niveau de protection adéquat qu'aux organisations inscrites sur la liste du cadre de protection des données tenue par le ministère américain du commerce. Discord, Inc. y figurait au 5 septembre 2026, pour les données hors ressources humaines, avec le statut public « recertification en cours d'examen » et une date de fin d'usage déjà passée. BALYS s'engage à reconsulter cette liste avant la mise en service de ce flux, puis à chaque revue de ses documents, et à suspendre le flux si l'organisation venait à en sortir — le même engagement que celui pris ci-dessous pour la Suisse. La qualification de ce prestataire au regard de l'article 28 pour ce flux, et l'acte qui l'encadrerait le cas échéant, ne sont pas arrêtés : c'est écrit au registre de BALYS et cela ne concerne aucune donnée du Client.

Les deux premiers, en détail, tous deux à destination de la Suisse :

1. Les courriels du service, acheminés par le serveur de messagerie d'Infomaniak. Six sortes de messages en partent — relevées une à une sur les fonctions d'envoi du logiciel, et non énumérées de mémoire ; la version 1.9 en annonçait cinq et oubliait la dernière : - les alertes d'échéance — adresse du destinataire, nom du fournisseur, date d'échéance ; - les rappels d'abonnement — adresse du destinataire, nom de l'abonnement, date du prélèvement attendu ; - les invitations à ouvrir un compte — nom et adresse de la personne invitée, et un lien à usage unique ; - les réinitialisations de mot de passe et confirmations d'adresse — adresse de la personne, et un lien à usage unique et de durée limitée ; - la correspondance d'assistance — les messages que le Client nous adresse et nos réponses. C'est la seule des six dont le contenu n'est pas prédéterminé : elle porte ce que le Client choisit d'y écrire, et peut donc citer une donnée de son espace s'il l'y recopie lui-même ; - l'avis interne d'une demande d'accès déposée sur le site public — adresse, entreprise et message que le demandeur a écrits lui-même, acheminés vers la boîte de l'exploitant. Il ne concerne jamais un Client ni son espace : il précède tout compte, et relève du traitement des demandes d'accès au registre de BALYS.

Aucun ne contient le document lui-même, et aucun ne transporte de mot de passe : les liens ne servent qu'à en choisir un.

Pour la correspondance d'assistance, la maîtrise revient au Client : ce qu'il n'écrit pas dans un courriel ne transite pas. Lorsqu'une demande exige d'examiner une donnée précise, BALYS l'invite à la désigner par sa référence dans l'application plutôt qu'à la recopier.

2. La copie de sauvegarde hors machine, déposée sur l'espace kDrive d'Infomaniak. Les archives y sont chiffrées en AES-256 avant leur envoi, avec une clé qui n'est ni détenue ni accessible par Infomaniak : ce prestataire ne détient que du chiffre.

Ces transferts sont fondés sur l'article 45 du RGPD : la Suisse fait l'objet d'une décision d'adéquation de la Commission européenne, la décision 2000/518/CE du 26 juillet 2000, dans sa version consolidée au 17 décembre 2016. Cette décision a été adoptée sous la directive qui a précédé le RGPD ; elle reste la décision applicable — elle n'a pas été remplacée par une décision nouvelle — et son maintien a été confirmé par le rapport de réexamen de la Commission du 15 janvier 2024 (COM(2024) 7 final, CELEX 52024DC0007), portant sur les onze décisions d'adéquation adoptées au titre de l'article 25, paragraphe 6, de la directive 95/46/CE, la Suisse comprise. Aucune garantie complémentaire n'est donc requise.

Aucune donnée du Client n'est transmise à un fournisseur d'intelligence artificielle : le modèle qui lit les contrats s'exécute sur une machine de l'exploitant, en France, jointe par un réseau privé chiffré.

Le réseau privé qui relie nos machines n'est pas qualifié, et c'est une condition de signature de ce contrat (É-4). Les machines qui composent le service communiquent entre elles par un réseau privé maillé, chiffré de bout en bout, du type WireGuard (Tailscale Inc.). Le contenu qui y circule n'est pas lisible par le fournisseur de ce réseau ; celui-ci traite en revanche des métadonnées de connexion — adresses publiques des machines, clés publiques, horodatages — et il est établi hors de l'Union, aux États-Unis.

Sa place dans le service est plus grande que ce que la version précédente décrivait, et il faut le dire avant de le qualifier : tout le trafic applicatif du site public transite par ce réseau — le serveur mandataire joint l'application à son adresse privée, et l'application n'écoute que sur cette adresse — et le nom d'hôte par lequel la bêta est joignable en interne, ainsi que son certificat, sont opérés par ce même fournisseur. Ce n'est donc pas une commodité d'administration ; c'est un chemin de service.

Ce que cela impose. L'article 28.2 ne connaît pas la catégorie « prestataire en cours de qualification » : ou bien il est autorisé et listé à l'annexe 3, ou bien il ne doit pas être engagé. BALYS ne demande donc pas au Client de signer en l'état : la qualification — sous-traitant ultérieur, ou opérateur de transport dont l'intervention se limite à l'acheminement — et, le cas échéant, le fondement du transfert de métadonnées, doivent être arrêtés avant signature, portés à l'annexe 3, et notifiés dans les conditions de l'article 8.

Deux trajets échappent à BALYS, et ils appartiennent au Client :

• un courriel ne s'arrête pas chez notre relais. Il est ensuite remis au serveur de messagerie du destinataire, que le Client choisit et non nous : si ses adresses sont hébergées hors de l'Union, le message y parvient. BALYS ne garantit donc le trajet des courriels que jusqu'à la remise au serveur du destinataire ;
• le flux calendrier, s'il est activé, est destiné à être lu par l'application d'agenda que le Client choisit. S'abonner à ce flux depuis un agenda hébergé hors de l'Union y transmet les dates d'échéance — le nom de l'espace, le titre et la description de chaque échéance, qui portent le nom du fournisseur concerné et les dates ; jamais un document ni un montant. L'activation comme l'extinction appartiennent au Client, et deux gestes distincts lui sont offerts : renouveler le lien, qui remplace une adresse publique par une autre adresse publique — l'ancienne cesse de répondre, le flux continue —, et supprimer le lien, qui éteint le flux : plus aucune adresse ne répond. Précision de la version 1.9 : jusqu'au 4 septembre 2026, seul le renouvellement existait, et « révocable » ne désignait que lui.

Précision de la version 1.8 : ce flux est accessible depuis l'internet public depuis le 4 septembre 2026. Le registre des traitements le décrivait encore comme joignable par le seul réseau privé ; c'est corrigé (C10), et la politique de confidentialité publiée décrit désormais ce trajet, qu'elle passait sous silence. L'autorisation tient entièrement dans un jeton de 192 bits présent dans l'adresse : il figure donc dans les journaux d'accès du serveur mandataire (trente jours) et, le cas échéant, dans ceux du fournisseur d'agenda choisi par le Client.

Si une décision d'adéquation venait à être invalidée ou abrogée, BALYS en informerait le Client sans délai et suspendrait le flux concerné jusqu'à mise en place d'une garantie appropriée au sens de l'article 46.

Article 10 — Assistance au Client

10.1 Droits des personnes concernées (article 28.3.e)

Le Client répond lui-même aux demandes qu'il reçoit. L'interface lui permet d'y répondre en partie, et il vaut mieux dire jusqu'où : il peut consulter les données de son espace, corriger une valeur extraite, supprimer un document — la ligne, ses extractions, ses événements et l'objet chiffré du stockage — et supprimer un abonnement.

Elle lui permet désormais d'exporter l'ensemble de ses documents disponibles et des données extraites, en une seule archive ZIP téléchargée directement depuis l'application — les PDF d'origine tels que déposés, et un fichier donnees.json portant les contrats, échéances, alertes, et la liste des documents absents de l'archive avec leur motif : un format ouvert et lisible par une machine, de quoi honorer une demande de portabilité au sens de l'article 20 que le Client recevrait de ses propres personnes concernées. Précision de la version 1.8 : ce n'est pas BALYS qui exécute ici l'article 20 — ce droit s'exerce contre le responsable du traitement, c'est-à-dire contre le Client. BALYS l'assiste, au titre de l'article 28.3.e ; la nuance décide qui répond devant qui. Ce que l'archive ne contient pas, et qu'il vaut mieux savoir avant d'en avoir besoin : ni les abonnements et leurs rappels, ni les fournisseurs, ni les traces d'analyse, ni le journal d'audit. Ces données restent accessibles dans l'application et peuvent être demandées à BALYS dans les conditions du présent article ; leur ajout à l'archive est un écart déclaré au registre (É-19). Trois motifs, et trois seulement, tiennent un document hors de l'archive, et chacun est inscrit dans donnees.json avec le nom du document, pour qu'aucune absence ne soit silencieuse : la mise en quarantaine par le contrôle antivirus au dépôt — pour la même raison que l'interface ne le rend jamais consultable, aucun contenu n'a alors été conservé —, l'absence de fichier conservé pour ce dépôt, et un fichier devenu illisible au moment de l'export. La version 1.9 n'écrivait que le premier ; les deux autres existent dans le logiciel depuis la mise en service de l'export. Un document dont le seul traitement (lecture, extraction) a échoué reste, lui, dans l'archive : le fichier appartient au Client, que son analyse ait réussi ou non. L'opération est réservée au propriétaire de l'espace, journalisée, et limitée en fréquence.

Elle lui permet désormais de fermer son espace lui-même — l'effacement au terme de la prestation, que l'article 28.3.g met à la charge de BALYS, et par lequel le Client peut ensuite honorer l'article 17 auprès de ses propres personnes concernées. Le propriétaire de l'espace saisit le nom exact de l'entreprise pour confirmer, et l'espace devient immédiatement inaccessible, à lui comme au reste de son équipe. La suppression réelle — base de données, documents déposés dans le stockage, et comptes qui n'appartiennent à aucun autre espace — intervient automatiquement trente jours plus tard, par une tâche planifiée du service : c'est le délai que promet l'article 11 ci-dessous, et il protège d'une fermeture demandée par erreur. Tant qu'il court, la fermeture est réversible : l'écran qui remplace l'application le rappelle, avec la date exacte de suppression, et permet d'annuler. La demande, comme l'annulation, est journalisée.

Lorsque l'interface n'y suffit pas, BALYS lui prête assistance dans un délai de dix (10) jours ouvrés à compter de sa demande écrite — délai calculé pour lui laisser de la marge sur le mois que lui accorde l'article 12.3.

Si une personne concernée s'adresse directement à BALYS, BALYS ne lui répond pas sur le fond : la demande est transmise au Client sous quarante-huit (48) heures, et la personne en est informée.

10.2 Autres obligations (article 28.3.f)

BALYS assiste le Client dans le respect des articles 32 à 36 — sécurité, notification des violations, analyse d'impact, consultation préalable — compte tenu de la nature du traitement et des informations dont il dispose.

Article 11 — Sort des données au terme de la prestation

Au terme de la prestation, le Client choisit entre la restitution et l'effacement de l'ensemble des données (article 28.3.g). À défaut de choix exprimé dans les trente (30) jours suivant le terme, l'effacement s'applique.

• Restitution : remise des documents déposés, tels qu'ils l'ont été, et des données qui en ont été extraites, sous quinze (15) jours à compter de la demande. Le propriétaire de l'espace peut désormais la déclencher lui-même, en libre service : un téléchargement depuis l'application produit une archive ZIP contenant les documents disponibles tels qu'ils ont été déposés et un fichier donnees.json portant les contrats, les échéances et les alertes qui en ont été extraits — un format ouvert et lisible par une machine (article 20). Trois motifs peuvent tenir un document hors de l'archive — mise en quarantaine par le contrôle antivirus, absence de fichier conservé pour ce dépôt, fichier devenu illisible au moment de l'export (article 10.1) ; donnees.json en tient néanmoins le compte, avec son motif, pour que cette absence soit visible plutôt que silencieuse — un document dont seul le traitement a échoué, lui, reste inclus. Le délai de quinze jours reste la garantie de repli pour le cas où l'espace ne serait plus accessible au Client au moment de sa demande — notamment un espace dont la fermeture (voir ci-dessous) a déjà été demandée. Ce que BALYS garantit est le contenu — rien de ce que le Client a déposé ou fait produire ne lui est retenu — et le délai.

La restitution est suivie de l'effacement : BALYS détruit les copies existantes dans les trente (30) jours qui suivent la remise, sans nouvelle demande du Client. Comment cet effacement s'exécute, précisé en version 1.8 parce que « sans nouvelle demande du Client » promettait autrement un mécanisme qui n'existe pas : la restitution se conclut par la fermeture de l'espace au sens de l'article 10.1, laquelle déclenche la suppression automatique à trente jours décrite ci-dessous et la journalise. Le contrat emprunte ainsi le seul chemin réellement outillé du produit ; à défaut de fermeture demandée par le Client, l'effacement reste un geste d'exploitation, tenu par une personne et non par une tâche planifiée — c'est le sens exact de l'engagement, et il est dit tel quel. Les sauvegardes font exception et suivent le cycle décrit ci-dessous. Il ne s'agit pas d'une réserve de style : purger sélectivement une archive chiffrée reviendrait à la réécrire, donc à perdre ce qui en fait une sauvegarde.

Cette obligation n'est pas une facilité de rédaction. L'article 28.3.g n'offre pas le choix entre restituer ou garder : il impose de restituer et de détruire les copies existantes. Un contrat qui s'arrêterait à la remise laisserait les données vivre sans terme dans nos systèmes.

• Effacement : suppression des données de la base et du stockage des documents sous trente (30) jours à compter de la demande ou, à défaut de choix exprimé, à compter de l'expiration du délai de trente jours prévu ci-dessus. Correction de la version 1.8 : le délai partait auparavant « du terme », alors que la règle par défaut ne se déclenche elle-même qu'à trente jours du terme — BALYS était en manquement à la seconde où l'obligation naissait.

Le chemin normal, pour le Client, est celui décrit à l'article 10.1 : fermer son espace lui-même. L'espace se ferme immédiatement, et la suppression réelle a lieu automatiquement trente jours plus tard — le délai même que promet cet article. Ce même délai s'applique quand l'effacement résulte, comme ci-dessus, de l'absence de choix exprimé au terme de la prestation.

Ce que cette suppression atteint, en une seule opération. La fermeture d'un espace efface en base, par cascade, ses documents et leurs versions, les textes et les extractions, les traces d'analyse, les contrats, les fournisseurs, les événements, les alertes, les abonnements et leurs rappels, le journal d'audit, les adhésions de ses utilisateurs, les preuves d'envoi que le Client a saisies — moyen, date et numéro de suivi de la lettre de dénonciation qu'il a postée — et les confirmations d'adresse ; retire les objets chiffrés du stockage correspondant à ces documents, un par un ; et supprime les comptes — adresse électronique, nom d'affichage, empreinte du mot de passe, secret de double authentification chiffré, codes de secours, demandes de réinitialisation — de toute personne qui n'a, après cette fermeture, plus accès à aucun autre espace. Un compte rattaché à un autre espace du service est conservé intact ; seul le rattachement à l'espace fermé disparaît.

Quatre traces survivent à cette suppression, et voici comment cette liste s'établit — plutôt qu'affirmée, elle se vérifie : tout ce qui porte la marque de l'espace disparaît avec lui par la cascade de la base de données ; ne peuvent donc survivre que les tables qui ne portent aucune marque d'espace, et il y en a huit. Quatre sont hors de propos ici — celle des espaces eux-mêmes, dont la ligne est effacée, et les trois qui portent les comptes, décrits au paragraphe précédent. Restent les quatre suivantes. Ce paragraphe a écrit « une trace, et une seule » en version 1.8, puis « deux traces, et il n'y en a pas d'autres » en version 1.9 : chaque décompte vérifié en découvrait un de plus, parce qu'il énumérait de mémoire au lieu de partir du critère.

La première : une preuve d'acceptation des conditions générales — identifiant du compte, adresse électronique, nom de l'espace, identifiant de la version acceptée, date et adresse IP — est conservée hors du cloisonnement par espace, pour établir cette acceptation si elle était contestée. Elle est effacée automatiquement cinq (5) ans après la suppression de l'espace, délai aligné sur la prescription de droit commun des actions personnelles (article 2224 du code civil) ; le décompte part de la fin de la relation, jamais de l'acceptation elle-même. BALYS est responsable du traitement pour cette trace, qu'il conserve pour son propre compte et non pour celui du Client : elle figure à ce titre à son registre (T9) et à l'encadré de l'annexe 1. Cette exception existait dans le logiciel depuis le 4 septembre 2026 ; le présent article affirmait jusqu'ici que la fermeture supprimait l'adresse électronique des comptes, sans réserve. Elle est nommée ici, la purge est écrite dans le produit et s'exécute à chaque passage de la tâche planifiée qui calcule les échéances, et la politique de confidentialité publiée le dit désormais aussi.

La seconde : la preuve de l'opération elle-même, journalisée hors du cloisonnement par client, précisément pour survivre à la suppression qu'elle documente : ancien identifiant de l'espace, nom de l'espace, nombre de comptes supprimés et conservés, objets de stockage effacés. Un résidu de stockage — un aléa réseau, jamais un objet déjà absent — y est consigné pour un traitement manuel plutôt que silencieusement perdu. Cette trace n'a aujourd'hui aucune durée d'effacement, et il vaut mieux l'écrire que de la laisser croire alignée sur la précédente : rien ne la purge, à aucune échéance. L'écart est déclaré au registre des traitements (É-17), et la durée qui lui manque a vocation à être celle de la preuve d'acceptation ci-dessus. Le nom de l'espace est le seul élément qui puisse désigner une personne, et seulement lorsque le Client est un entrepreneur individuel.

La troisième : l'empreinte des adresses auxquelles une demande de confirmation a été envoyée — une empreinte cryptographique de l'adresse et la date du dernier envoi, rien d'autre : ni l'adresse en clair, ni l'espace d'où l'envoi partait. Cette table existe pour empêcher qu'une même adresse soit sollicitée en boucle depuis plusieurs espaces, ce qui suppose qu'elle survive à chacun d'eux. Elle ne permet pas de retrouver une adresse, mais elle permet de vérifier qu'une adresse connue y figure : c'est une donnée pseudonyme et non anonyme, et elle n'a aujourd'hui aucune durée d'effacement.

La quatrième : la demande d'accès à la bêta, si la personne en a déposé une avant d'avoir un compte — adresse, entreprise et message qu'elle a écrits elle-même. Elle n'a jamais appartenu à l'espace fermé, ce qui est précisément pourquoi sa suppression ne l'emporte pas ; elle relève d'un traitement distinct, avec sa propre durée, décrit au registre des traitements de BALYS.

Les sauvegardes suivent leur propre cycle et ne peuvent pas être expurgées sélectivement — une sauvegarde que l'on modifie n'est plus une sauvegarde. La rotation conserve les sept dernières archives quotidiennes, les quatre derniers dimanches et les six premiers jours de mois : les données subsistent donc dans les archives chiffrées au maximum six (6) mois après l'effacement, durée au terme de laquelle la dernière archive les contenant est détruite. Pendant cet intervalle, elles ne sont ni accessibles ni exploitées par le service.

Une réserve sur la copie hors machine, que le script porte lui-même et que ce contrat ne reprenait pas : la rotation locale est calendaire, tandis que le distant est purgé par âge de dépôt (rclone delete --min-age 6M). Or l'espace distant ne préserve pas les dates de modification : cet âge mesure le temps écoulé depuis le dernier dépôt du fichier, non l'âge réel de l'archive. En fonctionnement normal, les deux coïncident. Après une resynchronisation ou une recopie d'anciennes archives, une archive pourrait subsister au-delà de six mois sans que rien ne le signale. Les six mois sont donc la règle et l'objectif ; ce n'est pas une garantie que le mécanisme sait tenir en toutes circonstances, et il vaut mieux l'écrire que de garantir ce qui ne l'est pas.

É-3 est levée : cette rotation s'applique désormais aux archives conservées sur le serveur et à leur copie hors site : la purge des archives distantes de plus de six mois s'exécute après chaque copie réussie, dans la même tâche planifiée que la sauvegarde.

Une exception, et il faut la dire plutôt que la taire : la vérification hebdomadaire des sauvegardes restaure une archive pour prouver qu'elle est restaurable — c'est la mesure de l'article 32.1.c et 32.1.d, et elle porte donc aussi sur des archives contenant encore les données d'un client parti. Cette restauration est automatique, sans intervention humaine, dans une base jetable dédiée (balys_verification), détruite à la fin de la vérification et même en cas d'échec. Aucune donnée n'y est lue, ni consultée, ni exportée : seuls des dénombrements sont comparés. Passé six mois, l'archive elle-même n'existe plus.

Article 12 — Violations de données

BALYS notifie au Client toute violation de données à caractère personnel le concernant dans les meilleurs délais et au plus tard vingt-quatre (24) heures après en avoir eu connaissance (article 33.2).

Le délai de vingt-quatre heures est un engagement contractuel de BALYS, plus strict que le règlement : il est calculé pour laisser au Client l'essentiel des soixante-douze heures dont il dispose lui-même pour notifier son autorité de contrôle (article 33.1).

La notification comporte les éléments de l'article 33.3 dans la mesure où ils sont connus : nature de la violation, catégories et nombre approximatif de personnes et d'enregistrements concernés, conséquences probables, mesures prises. Les éléments manquants sont communiqués de manière échelonnée, sans retard indu.

La procédure suivie par BALYS est décrite dans un document interne, Conduite à tenir en cas de violation de données, communiqué au Client sur demande.

Article 13 — Registre et documentation

BALYS tient le registre des catégories d'activités de traitement effectuées pour le compte de ses clients, exigé par l'article 30.2. Il est communiqué au Client sur demande, expurgé des informations relatives à ses autres clients.

BALYS n'a pas désigné de délégué à la protection des données. Aucune des trois conditions de l'article 37.1 n'est remplie : BALYS n'est pas un organisme public ; ses activités de base n'impliquent ni suivi régulier et systématique à grande échelle de personnes concernées, ni traitement à grande échelle de catégories particulières de données. Le point de contact pour toute question relative à la protection des données est contact@myracl.com.

Article 14 — Audit

BALYS met à la disposition du Client toutes les informations nécessaires pour apporter la preuve du respect des obligations du présent contrat et pour permettre la réalisation d'audits, y compris des inspections, par le Client ou un auditeur qu'il a mandaté, et y contribue (article 28.3.h). Correction de la version 1.8 : le texte disait « du présent article ». Dans le règlement, « présent article » désigne l'article 28 tout entier ; transposé dans un contrat dont l'article 14 est celui de l'audit, il revenait à n'obliger BALYS qu'à prouver qu'il se laisse auditer, ce qui privait l'audit de tout objet.

• Sur pièces : les annexes du présent contrat, le registre de l'article 30.2, et les éléments complémentaires demandés par écrit sont fournis sous trente (30) jours.
• Dans les locaux d'exploitation de BALYS, ou par un tiers mandaté : une fois par période de douze mois, moyennant un préavis écrit de trente (30) jours, pendant les heures ouvrables, et sans perturber l'exploitation. L'auditeur mandaté ne doit pas être un concurrent de BALYS et est tenu à la confidentialité. Pour les infrastructures exploitées par un sous-traitant ultérieur, ce droit s'exerce par la communication des rapports, certifications et accords que celui-ci met à disposition : BALYS ne contrôle pas les locaux de son hébergeur et ne peut pas donner accès à ce qui ne lui appartient pas. Correction de la version 1.8 : le contrat promettait un audit « sur place » sans réserve, alors que le siège déclaré est une adresse personnelle, que les données sont chez un hébergeur tiers, et que le moteur d'analyse tourne sur un poste de l'exploitant. Promettre ce qu'on n'a pas le pouvoir d'accorder n'aide personne.
• Un audit supplémentaire est de droit après une violation de données affectant le Client, sans attendre l'échéance annuelle, moyennant un préavis de cinq (5) jours ouvrés. La version précédente écrivait « sans préavis ni limitation de fréquence » : un engagement illimité, que le règlement n'exige pas et qu'un exploitant seul ne peut pas tenir. Le droit reste réel — c'est le moment où il sert le plus — et devient tenable.

Le premier audit annuel est à la charge de BALYS. Les suivants sont à la charge du Client, sauf s'ils révèlent un manquement, auquel cas leur coût est supporté par BALYS.

Article 15 — Responsabilité

Chaque partie assume les conséquences des manquements qui lui sont imputables. Le droit à réparation des personnes concernées est celui de l'article 82 du règlement : il leur appartient, et aucune stipulation du présent contrat ne le limite ni ne le répartit.

Articulation avec le plafond des conditions générales. La responsabilité de BALYS au titre du présent contrat est soumise au plafond stipulé à l'article 11 des conditions générales d'utilisation. Ce plafond ne s'applique ni en cas de faute lourde ou dolosive, ni aux réparations dues aux personnes concernées au titre de l'article 82 du règlement, ni au manquement à une obligation essentielle au sens de l'article 1170 du code civil.

Deux corrections en version 1.8. La première : les versions précédentes renvoyaient aux « articles 82 à 84 » du règlement. Les articles 83 et 84 sont les amendes administratives et les sanctions prévues par le droit national ; elles sont infligées par une autorité, et un contrat ne les répartit pas entre les parties. La seconde : l'article 1 fait prévaloir le présent contrat sur toute stipulation contraire des conditions générales, et cet article était muet sur tout plafond — deux lectures étaient possibles, l'une plafonnant la responsabilité de BALYS, l'autre la rendant illimitée, et ni le Client ni BALYS ne savait à quoi il s'engageait. Le point est tranché plutôt que laissé ouvert.

Article 16 — Non-respect du contrat et résiliation

Cet article manquait jusqu'à la version 1.8. C'est lui qui donne une conséquence aux quinze précédents : sans lui, le Client pouvait constater un manquement par l'audit de l'article 14 et n'en tirer aucune suite. Il reprend la structure de la clause 10 des clauses contractuelles types de la décision d'exécution (UE) 2021/915, calibrée sur ce qu'une micro-entreprise peut tenir.

16.1 — Droits du Client. En cas de manquement de BALYS aux obligations du présent contrat, le Client peut lui donner instruction de suspendre le traitement des données à caractère personnel jusqu'à ce qu'il s'y conforme ou que le contrat soit résilié. Le Client peut résilier le présent contrat et le contrat de service, sans frais ni indemnité :

1. lorsque le traitement est suspendu en application de l'alinéa précédent et que BALYS ne s'est pas conformé au contrat dans un délai d'un mois ;
2. en cas de manquement grave ou persistant de BALYS à ses obligations ;
3. lorsque BALYS n'exécute pas une décision contraignante d'une autorité de contrôle ou d'une juridiction compétente portant sur ses obligations au titre du présent contrat.

La résiliation ouvre droit au sort des données prévu à l'article 11 — restitution ou effacement, au choix du Client — et au remboursement au prorata des sommes versées d'avance.

16.2 — Droit symétrique de BALYS. BALYS peut résilier le présent contrat, en tant qu'il porte sur le traitement de données à caractère personnel, lorsque le Client, informé par écrit qu'une instruction lui paraît illicite (article 4), exige néanmoins qu'elle soit exécutée. Il en informe le Client par écrit, avec un préavis de trente (30) jours, et exécute l'article 11.

16.3 — Ce que BALYS peut tenir, et ce qu'il ne peut pas. Une suspension du traitement est, pour ce service, l'arrêt de l'accès à l'espace du Client : BALYS ne peut ni continuer à alerter, ni conserver un service partiel pendant une suspension. C'est dit ici pour que personne ne découvre après coup ce que « suspendre » veut dire pour un service d'alerte sur échéances.

Article 17 — Droit applicable

Le présent contrat est régi par le droit français. L'autorité de contrôle compétente pour BALYS est la Commission nationale de l'informatique et des libertés (CNIL).

Signatures

⚠️ À lire avant de signer, même si vous ouvrez le document à cette page. Ce contrat comporte trois conditions à lever, énumérées en tête sous « Avant de le signer » : les accords de sous-traitance ultérieure avec Hostinger et Infomaniak (É-10), la qualification du fournisseur du réseau privé par lequel passe tout le trafic applicatif (É-4), et l'inscription du Client au registre de l'article 30.2 (É-16). Tant que le tableau de ces conditions figure dans le document, celui-ci est un projet et non un contrat prêt à signer. Ce bloc annonçait « quatre conditions » — rotation des sauvegardes, secret dans le dépôt, cloisonnement, accords de sous-traitance — jusqu'à la version 1.8, alors que l'en-tête n'en portait que deux : c'était un reliquat non mis à jour, qui rouvrait à la page de la signature deux écarts que le corps du document déclarait fermés. Les deux listes disent désormais la même chose, et cette note reste pour que la correction se voie. Ce bloc disparaît en même temps que ce tableau.

Table de correspondance avec l'article 28

Elle n'est pas décorative : elle est le moyen de vérifier qu'aucune des mentions exigées ne manque. Chaque ligne renvoie à l'endroit du contrat qui la porte.

Trois stipulations ne sont exigées par aucune mention de l'article 28 et figurent néanmoins ici, parce que c'est ce qu'un service juridique cherche : la résiliation pour manquement (article 16, sur le modèle de la clause 10 des clauses types de la décision 2021/915), la copie de l'accord conclu avec un sous-traitant ultérieur (article 8, clause 7.7), et la conduite à tenir face à une demande d'autorité (article 4).

Annexe 1 — Description du traitement

Mentions exigées par l'article 28.3, premier alinéa.

Objet

Surveillance des échéances contractuelles du Client : détection des dates de reconduction tacite et des délais de préavis, et alerte avant leur expiration.

Nature des opérations

Collecte (dépôt par le Client), vérification antivirus, stockage sous forme chiffrée, analyse automatisée du texte, extraction d'informations, calcul de dates, consultation par les utilisateurs du Client, export de ses données par le propriétaire de l'espace, fermeture de son espace par le propriétaire, envoi d'alertes par courrier électronique, mise à disposition d'un flux calendrier si le Client l'active, sauvegarde, remise des données au terme de la prestation, effacement.

Finalité

Exclusivement l'exécution du service décrit à l'article 1. Aucune autre.

Catégories de personnes concernées

Catégories de données

Ce qui n'est PAS traité pour le compte du Client, et qu'il faut distinguer. Trois ensembles, dont deux étaient absents de cet encadré jusqu'à la version 1.8 :

1. Les données du compte d'accès lui-même — adresse électronique, nom d'affichage, empreinte du mot de passe, secret de double authentification chiffré, codes de secours, horodatages de connexion. Ces données vivent dans des tables communes à tout le service, un même compte pouvant accéder à plusieurs espaces, et elles survivent à la suppression de l'espace (article 11). BALYS en est le responsable du traitement, et non le sous-traitant du Client ; elles figurent à ce titre au registre des traitements de BALYS (traitement T7), qui expose le raisonnement.
2. La preuve d'acceptation des conditions générales — identifiant du compte, adresse électronique, nom de l'espace, identifiant de version, date et adresse IP. Conservée hors du cloisonnement, elle survit délibérément à la fermeture de l'espace et est effacée cinq ans après elle (article 11, registre T9). BALYS en est responsable du traitement : elle sert sa propre défense, au besoin contre le Client.
3. Le registre des suppressions d'espace — ancien identifiant de l'espace, nom de l'entreprise, nombre de comptes supprimés et conservés, objets de stockage effacés. Il documente l'exécution de l'effacement et serait sans objet s'il disparaissait avec lui. Il ne porte aucune donnée de personne physique, sauf lorsque le nom de l'entreprise est celui d'un entrepreneur individuel. Il n'a à ce jour aucune durée d'effacement — écart déclaré au registre (É-17), à aligner sur les cinq ans du point 2.

Ce que le présent contrat couvre, c'est le rattachement d'un utilisateur à l'espace du Client, décidé par lui.

Conséquence pratique, qu'il faut tirer plutôt que laisser au lecteur : puisque BALYS est responsable du traitement pour ces trois ensembles, c'est à lui — et non au Client — d'informer les personnes concernées au titre des articles 13 et 14. Il le fait par la politique de confidentialité publiée à https://balys.myracl.com/confidentialite, à laquelle les conditions générales renvoient également.

Aucune catégorie particulière de données au sens de l'article 9 n'est demandée, ni attendue, ni exploitée. Le service est conçu pour des contrats fournisseurs — énergie, télécoms, assurances, maintenance, logiciels. Il appartient au Client de ne pas y déposer de documents contenant de telles données (article 5.3) ; le service ne les recherche pas et n'en tire aucune conclusion.

Le relevé bancaire éventuellement utilisé pour retrouver des abonnements n'est jamais transmis à BALYS : il est lu dans le navigateur du Client, et seules les lignes qu'il valide parviennent au service.

Durée du traitement

Pour toute la durée du contrat de service, puis dans les conditions de l'article 11.

Par catégorie, quand elle diffère de cette règle générale — le modèle de registre de la CNIL attend cette précision, et une durée unique la masquait :

Annexe 2 — Mesures techniques et organisationnelles

Exigées par l'article 32, et par l'article 28.3.c qui y renvoie. Chaque ligne décrit ce qui est en place et a été confronté au code, pas ce qui est prévu.

Cloisonnement entre clients

Le cloisonnement repose sur deux mécanismes, et il faut dire lequel s'applique où plutôt que d'annoncer le plus fort pour les deux.

1. Par la base de données, pour les données métier du Client. Toute table portant une colonne d'organisation est placée sous le mécanisme de sécurité au niveau des lignes de PostgreSQL, activé et forcé, avec une politique (tenant_isolation) qui compare l'organisation de chaque ligne à celle posée dans la session. L'application n'atteint ces tables qu'en posant d'abord ce contexte d'organisation, et se connecte avec un rôle explicitement non superutilisateur, distinct du rôle propriétaire réservé aux migrations — ce détail est la clé du dispositif, un superutilisateur contournant la politique même forcée. Sur ces chemins, une requête émise sans contexte d'organisation ne renvoie aucune ligne : un oubli produit une absence de résultat, jamais les données d'un autre client. Sont ainsi protégées les tables qui portent l'essentiel de ce que le Client confie : documents et leurs versions, textes extraits, extractions, contrats, fournisseurs, événements, alertes, abonnements et rappels, journal d'audit, adhésions, confirmations d'adresse, traces d'analyse.

2. Par le code, ailleurs. Les tables communes à tout le service — comptes, codes de secours, demandes de réinitialisation, organisations, demandes d'accès, compteur anti-abus, registre des suppressions d'espace et preuves d'acceptation des conditions générales — n'ont pas de colonne d'organisation et échappent par construction au mécanisme précédent. Leur usage est borné par le code. Les deux dernières manquaient à cette énumération jusqu'à la version 1.8 : elles portent délibérément un identifiant d'origine plutôt qu'une colonne d'organisation, précisément pour survivre à la suppression qu'elles documentent — ce qui les place, tout aussi délibérément, hors du mécanisme de la base. Une énumération de ce genre ne vaut que si elle est complète.

Ce qui contournait ce mécanisme depuis l'application a été corrigé (É-7, levée). Certains chemins interrogeaient la base avec le rôle propriétaire, qui contourne la sécurité au niveau des lignes, et s'appuyaient sur un filtre écrit dans le code. Il ne reste que trois exceptions nommées, dans deux fichiers — chacune testée pour son isolation — et une suite de tests dédiée échoue si un appel de plus apparaît sans être déclaré.

Cela ne rend pas pour autant le cloisonnement intégralement porté par la base. Les tables énumérées au point 2 ci-dessus — comptes, codes de secours, demandes de réinitialisation, organisations, demandes d'accès, compteur anti-abus, registre des suppressions, preuves d'acceptation — n'ont, par construction, aucune colonne d'organisation : elles échappent à la sécurité au niveau des lignes quel que soit le rôle qui les lit, et le resteront tant que le schéma n'en décide pas autrement. BALYS ne revendique donc pas un cloisonnement intégralement porté par la base : il l'est, par la base, pour les données métier du Client (point 1) ; il est porté par le code pour ces tables communes à tout le service (point 2).

Chiffrement

Contrôle d'accès

• Authentification par mot de passe ; double authentification par code temporaire (TOTP, RFC 6238) disponible pour tous les comptes, assortie de codes de secours à usage unique et d'une garde contre le rejeu d'un code déjà présenté.
• Aucune inscription libre : un compte ne peut être créé que par invitation nominative. La seule page de création qui existe est celle de l'amorçage, qui sert à créer le tout premier compte du service : elle se ferme d'elle-même dès qu'un compte existe (sauf réglage contraire, qui est désactivé) et elle est en outre rendue introuvable depuis l'internet public par le serveur mandataire.
• Limitation des tentatives de connexion, sur trois décomptes et par fenêtre de 15 minutes : 20 échecs par adresse appelante, refus d'un compte dès que 5 adresses appelantes distinctes y ont échoué, et refus d'un compte au-delà de 40 échecs quelle qu'en soit la provenance. Seuls les échecs sont comptés. Le décompte par adresses distinctes fait qu'une seule machine acharnée ne peut pas fermer l'accès d'un client dont elle ne connaît que l'adresse électronique — 40 est hors d'atteinte d'une machine unique, bornée à 20 ; le plafond de 40 borne, lui, l'attaque répartie, qu'un décompte d'adresses seul laissait progresser tant qu'elle restait sous 5 machines. Les compteurs sont partagés entre toutes les instances du service, et une panne du compteur fait refuser la connexion plutôt que de l'autoriser.
• Révocation immédiate de toutes les sessions ouvertes d'un compte lors d'une réinitialisation de mot de passe : le jeton porte un numéro de génération confronté à la base à chaque requête.
• Vérification de possession des adresses d'alerte : tant qu'une adresse n'est pas confirmée par son titulaire, elle ne reçoit rien et les alertes partent à l'adresse du propriétaire de l'espace. Un plafond d'un envoi par adresse et par heure, commun à toutes les organisations, empêche que cette fonction serve à importuner un tiers.
• Tous les services de données n'écoutent que sur l'interface locale du serveur ; l'application n'est joignable que par le réseau privé et par le serveur mandataire. Aucune interface d'administration n'est exposée sur l'internet public.

Intégrité et traçabilité

• Journal d'audit de toutes les actions faites dans l'espace du Client : auteur, action, objet, valeur antérieure et nouvelle, horodatage. Il porte aussi les connexions au service, réussies et manquées, avec l'adresse IP d'où elles viennent. Deux durées distinctes, à ne pas confondre : les événements vivent aussi longtemps que l'espace et disparaissent avec lui ; l'adresse IP en est retirée après douze mois, automatiquement, l'événement restant. Ajouté en version 1.8 : ni la présence de cette adresse, ni sa durée ne figuraient nulle part, et les « 30 jours » de la ligne suivante pouvaient être lus comme la couvrant.
• Journal d'accès du serveur mandataire, conservé 30 jours au plus puis effacé par rotation automatique. Cette durée ne vise que ce journal-là, et non le journal d'audit ci-dessus. Réserve ajoutée en version 1.10, après vérification du réglage réel : la rotation se déclenche à la TAILLE du fichier, jamais à l'heure, et le délai de trente jours ne borne que les fichiers déjà renouvelés. Le seuil a été abaissé pour que le fichier en cours soit renouvelé tous les deux jours au trafic observé, ce qui rend la borne effective ; elle dépend néanmoins du trafic, et l'écart est déclaré au registre des traitements de BALYS.
• Vérification antivirus de tout document au dépôt (ClamAV), avant tout traitement ; un document dont l'analyse n'a pas pu s'exécuter part en quarantaine plutôt que d'être accepté.
• Toute donnée extraite par le modèle est marquée comme telle et reste soumise à la validation du Client : aucune alerte ne peut naître d'une donnée non validée, et le service n'affirme jamais une échéance sans indiquer d'où elle vient.

Protection du navigateur

Politique de sécurité du contenu fermée aux origines extérieures : aucun script, aucune feuille de style, aucune connexion, aucun formulaire vers un autre domaine ; la seule origine distante admise est celle des images de la vitrine. Elle autorise en revanche les scripts et les styles écrits dans la page elle-même ('unsafe-inline'), que le cadre de travail utilisé pose : ce n'est donc pas un rempart complet contre l'injection de script, et il serait inexact de la présenter comme telle. Elle empêche en tout état de cause l'exécution d'un script venu d'ailleurs et l'envoi de données vers un tiers.

S'y ajoutent l'interdiction de l'affichage en cadre, l'interdiction de la devination du type de contenu, une politique de référent restrictive et une politique de permissions qui n'accorde aucune capacité du navigateur.

Aucun traceur, aucun cookie tiers, aucun script extérieur dans l'application. Le seul cookie déposé est celui de session.

Disponibilité et résilience

Ce qui est garanti est la DURABILITÉ, pas la disponibilité, et il vaut mieux l'écrire ici que de le laisser découvrir. Le service repose sur trois machines — le serveur applicatif, le serveur mandataire public et la machine qui exécute le modèle de langue — et aucune des trois n'a de doublure : ni redondance, ni bascule automatique, ni répartition de charge. La perte de l'une interrompt le service jusqu'à son rétablissement. Les conditions générales d'utilisation le disent déjà (article 4.7) ; il serait singulier que le document signé soit le moins franc des deux. Les alertes dues pendant une interruption ne sont pas perdues : la tâche planifiée les reprend à son passage suivant. Ce que les mesures ci-dessous assurent, c'est qu'aucune donnée ne disparaisse — sauvegardes chiffrées, copie hors machine, restauration vérifiée — au sens des points c) et d) de l'article 32.1.

• Sauvegarde chiffrée quotidienne — base, documents et clés — à 3 h 30.
• Copie hors machine sur un espace distant, indépendante du serveur.
• Restauration vérifiée chaque lundi, automatiquement, à partir de la copie distante — et non de la copie locale, qui n'existerait plus en cas de sinistre. Une copie distante vide est traitée comme une panne.
• Alerte immédiate en cas d'échec d'une sauvegarde ou d'une vérification : l'unité de service sort en erreur, ce que la supervision voit.
• Rotation : 7 derniers jours, 4 derniers dimanches, 6 premiers du mois — au-delà de six mois, aucune archive n'est conservée, de sorte qu'un effacement demandé finit par s'appliquer partout. É-3 est levée : la purge s'applique aux archives du serveur et à la copie hors site (rclone delete --min-age 6M, exécuté après chaque copie réussie). Le mot « garantit » a été retiré en version 1.8 : la rotation locale est calendaire, tandis que le distant est purgé par âge de dépôt, et l'espace distant ne préservant pas les dates de modification, une resynchronisation pourrait prolonger cette durée sans rien signaler. Le script le documente lui-même ; le contrat ne peut pas garantir ce que le mécanisme sait ne pas tenir en toutes circonstances.

Organisation

• Les secrets d'exploitation — clé de chiffrement, secret de session, identifiants de messagerie — vivent dans un fichier accessible au seul compte d'exploitation, hors du dépôt de code, et sont chargés au démarrage. La réserve É-5 qui accompagnait cette ligne est levée : l'historique du dépôt a été purgé et vérifié le 4 septembre 2026, et l'affirmation ci-dessus est vraie sans réserve pour ce dépôt ; la rotation du mot de passe en base a par ailleurs été vérifiée. Ce qui reste — deux archives de l'historique d'avant-purge conservées hors du dépôt — est déclaré au registre (É-13) et ne porte plus sur une affirmation du présent contrat. Cette réserve était par ailleurs mal rattachée : elle figurait aussi à l'article 7, comme si elle visait une mesure de la présente annexe, alors qu'elle portait sur l'historique du dépôt.
• La clé qui déchiffre les sauvegardes n'est jamais déposée sur l'espace où les archives sont envoyées — l'y ranger reviendrait à ne pas les chiffrer — et le script de sauvegarde refuse de s'exécuter si elle est absente ou si ses droits sont trop larges. Une copie est conservée hors de la machine sauvegardée, et sa présence est contrôlée à chaque vérification hebdomadaire. Formulation corrigée en version 1.8 : le contrat énonçait comme un fait acquis que la clé « ne se trouve pas sur la machine sauvegardée seule ». La moitié négative est tenue par le script ; la moitié positive dépend d'un geste manuel de l'exploitant, dont l'absence ne produit aujourd'hui qu'un avertissement non bloquant à la vérification hebdomadaire. Le témoin de cette copie existe bien à la date de cette version ; ce qui est promis ici est donc la copie et son contrôle, pas une garantie que le mécanisme rendrait impossible d'oublier.
• Les services de données — base, cache, stockage des documents, antivirus — ne sont joignables que depuis le serveur lui-même, et non depuis le réseau.

Deux mesures figuraient ici en version 1.1 et en ont été retirées : un contrôle de sécurité quotidien du serveur et l'isolation des installations de dépendances dans un conteneur. La ligne d'évaluation régulière qui reprenait la première a été retirée avec elle en version 1.3 — la maintenir là en aurait fait une obligation contractuelle au moment même où on la retirait des mesures. Elles correspondent à des pratiques d'exploitation réelles, mais elles reposent sur des outils qui ne font pas partie de ce dépôt et n'étaient donc pas vérifiables ici. Une mesure contractuelle doit pouvoir être montrée ; celles-ci reviendront quand elles pourront l'être.

La machine d'analyse

Section ajoutée en version 1.8. Toutes les mesures ci-dessus décrivent le serveur ; aucune ne s'appliquait à la troisième machine, celle qui exécute le modèle de langue — et c'est pourtant elle qui reçoit de courts passages des contrats du Client. Un service juridique le formulera ainsi : « vous nous dites que nos contrats ne partent pas chez un fournisseur américain, et vous ne dites rien de la machine où ils vont ». Voici ce qui peut être montré, et ce qui ne peut pas encore l'être.

Ce que le code établit, et qui est vérifiable dans le dépôt :

• cette machine est jointe par le seul réseau privé : l'adresse configurée est une adresse de ce réseau, jamais un nom public ;
• elle ne reçoit jamais le document : l'extraction repère d'abord des passages candidats par motifs, puis n'envoie au modèle qu'une question et la phrase où le motif a accroché. Le reste du contrat ne quitte pas le serveur ;
• ce qui a été soumis est conservé côté BALYS, dans l'espace du Client (traces d'analyse de l'annexe 1), ce qui rend vérifiable l'origine de toute date affichée — et permet, à l'inverse, de savoir exactement ce qui est passé par cette machine ;
• aucune donnée n'est transmise à un fournisseur d'intelligence artificielle : le modèle s'exécute là, et nulle part ailleurs.

Ce qui n'est pas encore établi, et qui est déclaré plutôt qu'affirmé : le chiffrement du disque de cette machine, le contrôle d'accès qui la protège, sa sécurité physique, et surtout la garantie que le moteur ne journalise pas les passages soumis. Cette dernière affirmation figurait ailleurs dans le présent contrat et au registre sans avoir été vérifiée sur la machine elle-même ; elle est déclarée comme écart au registre (É-20) et sera portée ici, en mesure opposable, une fois contrôlée. En attendant, ce que BALYS s'engage à faire ne dépend pas de ce contrôle : ne soumettre que de courts passages, et jamais le document.

Mises à jour et vulnérabilités

Cette annexe ne comporte aucune mesure de gestion des vulnérabilités depuis la version 1.3, où deux mesures ont été retirées faute de pouvoir être montrées. Le vide est signalé ici plutôt que comblé par une phrase : la seule ligne vérifiable aujourd'hui est la suite de tests automatisés exécutée à chaque modification (voir « Évaluation régulière »). Une mesure de mise à jour ne sera inscrite ici que lorsqu'elle pourra être montrée, comme le reste de cette annexe.

Évaluation régulière

Exigée par l'article 32.1.d :

Annexe 3 — Sous-traitants ultérieurs autorisés

Article 28.2 et 28.4. Liste arrêtée au 4 septembre 2026.

Accords conclus avec ces prestataires (article 28.4)

L'article 28.4 n'impose pas seulement de nommer les sous-traitants ultérieurs : il impose de leur imposer par contrat les mêmes obligations de protection des données. C'est une obligation de résultat, et un tableau qui les nomme sans dire si cet accord existe ne la remplit pas.

Ces deux lignes doivent être renseignées avant signature (condition É-10). Aussi longtemps qu'elles ne le sont pas, BALYS ne peut pas démontrer avoir satisfait à l'article 28.4, et le Client ne peut pas démontrer avoir satisfait à l'article 28.1.

À trancher avant signature — le fournisseur du réseau privé

Tailscale Inc., États-Unis. Le trafic y est chiffré de bout en bout et ce fournisseur ne peut pas le lire ; il traite en revanche des métadonnées de connexion. Ce n'est pas une dépendance périphérique : tout le trafic entre le serveur mandataire public et l'application passe par ce réseau, et le nom d'hôte par lequel la bêta est jointe en interne, ainsi que son certificat, sont opérés par ce même fournisseur.

Sa qualification — sous-traitant ultérieur au sens de l'article 28.4, ou opérateur de transport dont l'intervention se limite à l'acheminement — et, le cas échéant, le fondement du transfert de métadonnées, doivent être arrêtés avant la signature et portés dans le tableau ci-dessus. La version 1.7 rangeait ce point sous « en cours d'instruction », sans échéance. L'article 28.2 ne connaît pas cette catégorie : ou bien un prestataire est autorisé et listé, ou bien il ne doit pas être engagé. Le point devient donc une condition de signature (É-4) plutôt qu'une promesse de dire plus tard.

Ce qui n'est pas un sous-traitant ultérieur

Le moteur d'analyse des contrats. Le modèle de langue qui lit les documents s'exécute sur une machine appartenant à l'exploitant, située en France sous la même réserve que celle de l'article 9 — l'adresse publique de cette machine relève d'une plage enregistrée en France, ce qui n'est pas une attestation —, jointe au serveur par un réseau privé chiffré. Il n'est appelé qu'avec de courts passages du contrat, jamais avec le document entier, et aucune donnée n'est transmise à un fournisseur d'intelligence artificielle. La version 1.7 ajoutait « ni conservée par le moteur au-delà du temps de la réponse » ; cette affirmation porte sur la configuration d'une machine qui n'a pas été contrôlée, et elle est retirée jusqu'à ce qu'elle le soit — voir l'annexe 2, « La machine d'analyse », et É-20 au registre.

Le salon de sécurité où sont postées les alertes d'intrusion. BALYS surveille son journal d'audit pour détecter un accès illégitime (article 4), et les signaux partent dans un salon privé hébergé par Discord Inc. (États-Unis).

Corrigé en version 1.11 : ce dispositif est en marche. Ses deux tâches automatiques — le détecteur, toutes les deux minutes, et le récapitulatif quotidien — avaient été activées le 4 septembre 2026 à 21 h 37, puis désactivées le soir même à la lecture de deux relectures juridiques, avant que le code ne soit corrigé. Elles ont été remises en service le 5 septembre 2026 à 08 h 37 (UTC), une fois cette correction faite. Les versions 1.9 et 1.10 les décrivaient à l'arrêt : c'était exact quand elles ont été écrites. Ce qui suit décrit donc désormais ce qui part de ce salon — étant précisé qu'aucun signal n'y a encore été produit, chaque passage du détecteur n'ayant trouvé aucune ligne à examiner.

Ce prestataire n'est pas un sous-traitant ultérieur, parce qu'il ne reçoit aucune donnée du Client : ce qui serait posté est un identifiant technique d'organisation, un identifiant technique de compte, l'identifiant de la ligne de journal, le verbe de l'action, un horodatage et des indicateurs — jamais un nom, une adresse électronique, un nom d'entreprise ni une adresse IP. La restriction est faite avant le message, à la lecture : le détecteur ne charge de la ligne de journal que les six colonnes dont il a besoin, et l'adresse IP, qui vit dans une colonne au format libre qu'aucune requête ne sait découper, est écartée dès la sortie de la requête par une reconstruction de la ligne à partir des seuls indicateurs lus — jamais par un retrait des champs connus, qui laisserait passer ceux qu'on n'aurait pas prévus. Un champ qui n'est pas chargé ne peut pas fuir ; les tests qui inspectent le message ne sont que la seconde ligne. Savoir qui est concerné suppose d'ouvrir la base de BALYS, ce qui ne se fait que depuis son infrastructure, par une commande locale que chaque alerte rappelle.

Ce raisonnement est écrit, avec ses limites, au registre des traitements (T8) : ces identifiants restent des données pseudonymisées — donc personnelles — pour BALYS, et la position soutenue est qu'ils ne sont pas des données personnelles du point de vue du destinataire, faute pour lui de moyen raisonnable de réidentifier (CJUE, 4 septembre 2025, C-413/23 P). Les lignes directrices 01/2025 du CEPD retiennent en règle générale la solution inverse, et un identifiant stable permet d'isoler un compte d'un message à l'autre. La position est déclarée comme telle au registre (É-18), et non présentée comme acquise. Jusqu'au 4 septembre 2026, ces alertes portaient bien un nom, une adresse électronique et une adresse IP ; le code a été corrigé le jour même, et un test échoue si l'un d'eux réapparaît dans un message.

C'est la différence de fond avec les services concurrents, qui envoient les contrats de leurs clients à un fournisseur américain.

Ce qui ne concerne pas les données du Client

Les images d'illustration du site vitrine public sont aujourd'hui chargées depuis les serveurs d'Unsplash Inc. (Canada), qui reçoit à cette occasion l'adresse IP des visiteurs de la page d'accueil.

Cela ne concerne en rien les données du Client : aucune page de l'application n'appelle de ressource extérieure, et ce tiers ne reçoit jamais la moindre donnée de son espace. Il ne figure donc pas parmi les sous-traitants ultérieurs, et n'appelle aucune autorisation au titre de l'article 8.

Pour mémoire : les conditions d'utilisation attachées à ces images imposent de les charger depuis leurs serveurs. Nous prévoyons donc de les remplacer par des images que nous hébergerons nous-mêmes, ce qui supprimera l'échange. Le traitement correspondant est décrit au registre de l'article 30.1 (T6).

Le rapport de fréquentation du site vitrine (flux 6 de l'article 9) est publié chaque heure dans un troisième salon du même prestataire américain. Il ne porte que des totaux — visites, visiteurs distincts comptés au moyen d'une clé jetable jamais transmise, gabarits de page et domaines de provenance — et il est calculé sur le journal du site public, jamais sur l'application. Aucune donnée du Client n'y entre, et rien de ce qui identifie un visiteur n'en sort. Ce qui a été corrigé le 5 septembre 2026, et qu'il vaut mieux écrire : ce rapport comptait les pages par leur adresse exacte, y compris celle du flux calendrier — laquelle porte un jeton secret qui suffit à lire les échéances d'une organisation. Aucun client ne détenait un tel lien à cette date, donc rien n'est parti ; les adresses sont désormais repliées sur leur gabarit avant tout décompte, et un test échoue si un jeton réapparaît dans le rapport.

Le salon où BALYS décide d'ouvrir un accès à la bêta (flux 7 de l'article 9) est un quatrième salon du même prestataire américain. BALYS y publie la demande déposée sur son site public — l'adresse électronique, le nom de l'entreprise et le message que la personne a écrits elle-même — et tranche d'une réaction : ouvrir l'accès, ou refuser en écrivant à la personne.

Ce prestataire n'est pas davantage un sous-traitant ultérieur à ce titre, parce qu'il ne reçoit aucune donnée du Client — et ici la raison est plus franche que pour le salon de sécurité : ce flux précède tout compte et tout espace. La personne dont les données y figurent n'est pas un Client ; elle demande à le devenir, et BALYS est responsable du traitement de sa demande, non sous-traitant. Ces données-là identifient, et le contrat ne prétend pas le contraire : elles sont couvertes par le registre de BALYS, avec le fondement de transfert exposé à l'article 9. Ce qui compte pour le Client tient en une phrase : la raison sociale d'une organisation cliente ne part jamais par ce canal. Lorsque le nom saisi par un demandeur ressemble à celui d'un Client existant, l'avertissement publié ne porte qu'un identifiant technique et le genre de ce qu'il a trouvé — jamais l'écriture réelle du nom, qui est celle d'un Client. La résoudre suppose une commande exécutée sur l'infrastructure de BALYS.

Ce flux est en service depuis le 7 septembre 2026 : l'unité qui le fait <!-- état-unité: balys-acces-beta.service --> tourner a été installée et démarrée ce jour-là. La version 1.11 le décrivait non installé — c'était exact à sa date, et faux dès le lendemain. Cette phrase-ci avait échappé au contrôle qui relie les textes aux services, faute de porter sa marque ; elle la porte désormais.

Le salon de la veille d'intégrité, et le seul compte de robot qui ne soit pas partagé

Le salon où BALYS surveille l'intégrité de son propre périmètre (flux 8 de l'article 9) est un cinquième salon du même prestataire américain. Un dispositif y publie, tous les quarts d'heure, ce qui s'écarte de ce que ce périmètre devrait être : un objet témoin du stockage qui ne se déchiffre plus — le signe d'un rançongiciel —, une archive de sauvegarde qui disparaît ou rétrécit, une tâche planifiée dont le texte a changé, le cloisonnement de la base qui n'est plus complet, une table qui perd la moitié de ses lignes, un fichier posé dans le dépôt de code que personne ne revendique, un document mis en quarantaine par l'antivirus, ou une rafale de dépôts, de consultations ou de suppressions dans l'heure.

Ce prestataire n'est pas davantage un sous-traitant ultérieur à ce titre. Sept détecteurs composent ce dispositif ; cinq ne regardent aucune personne — un objet témoin sans contenu, le dépôt de code, les tâches planifiées, les archives de sauvegarde et le catalogue de la base. Les deux qui lisent le journal d'audit publient un identifiant technique d'organisation, l'identifiant de la ligne de journal, le verdict rendu par l'antivirus, le verbe de l'action, un horodatage et des compteurs — jamais un nom, une adresse électronique, un nom d'entreprise, une adresse IP, ni le compte qui a agi, et pas davantage l'identifiant technique du document : il est lu pour que la commande locale de détail sache quoi rechercher, et il n'entre dans aucun message. La version 1.12 le déclarait publié. C'était faux, et faux du côté prudent — le contrat annonçait plus que ce qui part. Ce canal publie donc moins que le flux 4, qui emporte, lui, l'identifiant du compte qui a agi.

Le nom du fichier que le Client a déposé ne sort pas de nos machines, et la garantie est prise à la racine. La ligne de journal d'une mise en quarantaine porte ce nom — « Contrat_Dupont_2026.pdf » désigne une personne et une entreprise aussi sûrement qu'une raison sociale. La lecture ne charge que cinq colonnes, et chaque ligne est reconstruite dès la sortie de la requête pour ne garder que le verdict technique : jamais un retrait des champs connus, qui laisserait passer ceux qu'on n'aurait pas prévus. Savoir quel document est concerné suppose d'ouvrir la base de BALYS, ce qui ne se fait que depuis son infrastructure, par une commande locale que chaque message rappelle.

Ce canal a son propre compte de robot, et c'est le seul des cinq. Son jeton ne peut écrire que dans ce salon, et il se révoque sans faire taire les alertes de sauvegarde, celles de sécurité ni le circuit des demandes d'accès. Un canal qui surveille l'intégrité doit pouvoir être coupé le jour où c'est lui qu'on soupçonne ; et un dispositif de surveillance qui détiendrait la clé de tout ce qu'il surveille est exactement ce qu'on cherche à éviter. Ce que cela change pour le Client : une fuite de ce jeton n'ouvre que ce salon-là.

Le raisonnement de qualification est celui du salon de sécurité, et il n'est pas refait : ces identifiants restent des données pseudonymisées — donc personnelles — pour BALYS, et la position soutenue est qu'ils ne sont pas des données personnelles du point de vue du destinataire. Les mêmes limites s'appliquent, et un canal de plus ne les réduit pas. Elles sont déclarées au registre des traitements (T10, É-18, É-24 et É-27), avec deux réserves propres à celui-ci : le chemin d'un fichier non suivi et le nom d'un rôle de base de données sont publiés tels quels, si bien qu'un fichier client déposé à la main dans notre dépôt de code, ou un rôle créé au nom d'une personne, y feraient entrer un nom. Aucun de ces deux gestes n'est celui d'un Client ; les deux sont dans les mains de BALYS, et c'est à ce titre qu'ils sont écrits ici plutôt que tus.

Ce dispositif détecte, il ne bloque pas, et trois choses lui échappent par nature — elles sont dites ici entières, une limite à moitié dite valant moins que pas de limite du tout. Il ne coupe aucun service et ne supprime rien. Il ne voit rien entre deux passages. Et il ne se voit pas lui-même : qui contrôle le compte qui l'exécute peut l'arrêter ou lui faire dire que tout va bien. Deux de ses angles morts sont en outre déclarés : une tâche récurrente créée sans fichier d'unité lui est invisible, et une érosion lente — une archive de sauvegarde de moins par jour, quelques pour cent de lignes en moins à chaque passage — ne franchit aucun de ses seuils, qui comparent un passage au suivant.

Ce flux est en service depuis le 9 septembre 2026. <!-- état-unité: balys-integrite.timer --> Jusqu'à cette date, le code existait, l'unité qui le fait tourner n'était ni installée ni démarrée, et rien n'en était parti.

Toute mise à jour du tableau des sous-traitants ultérieurs — ajout ou remplacement — est notifiée au Client trente jours à l'avance, dans les conditions de l'article 8. Précision de la version 1.8 : cet engagement ne vaut que pour ce tableau. Les sections « moteur d'analyse », « salon de sécurité » et « images du site vitrine » ne décrivent pas des sous-traitants ultérieurs ; les tenir sous le même préavis aurait fait promettre trente jours d'avance pour corriger une description. Il en va de même de la section « rapport de fréquentation », ajoutée en version 1.10, et de celle du « salon des demandes d'accès », ajoutée en version 1.11 — laquelle ne décrit pas davantage un sous-traitant ultérieur, aucune donnée du Client n'y passant. Il en va de même de la section « salon de la veille d'intégrité », ajoutée en version 1.12.

Journal des révisions

Ce journal n'existait pas avant la version 1.8. Le registre des traitements en tient un depuis sa création ; ce document, qui est celui que le Client signe, n'en avait aucun — un contrat dont on ne peut pas dire ce qui a changé d'une version à l'autre demande au signataire de le relire en entier à chaque fois.