Le droit dans notre code

Quand nous avons rendu Premium achetable, nous pensions que la partie juridique se résumait à quelques pages de texte dans le pied de page. C'était faux. Certaines obligations ne peuvent pas du tout être écrites dans un texte, parce qu'elles dictent la manière dont une fonctionnalité doit être construite.

Quatre exemples où cela est devenu particulièrement clair. D'emblée, pour qu'il n'y ait pas de malentendu : il s'agit d'une description de notre implémentation, pas d'un conseil juridique. Les règles ci-dessous relèvent du droit allemand, celui sous lequel AlphaCloud opère.

Le bouton de résiliation qui ne doit pas exiger de connexion

L'article 312k du Code civil allemand impose aux contrats conclus en ligne de proposer un moyen de résiliation directement accessible. Cela crée des exigences qu'on ne peut pas ajouter après coup dans la formulation :

• La page doit fonctionner sans connexion
• Elle doit se trouver dans le pied de page de chaque page
• Elle a besoin de deux étapes : saisir, puis confirmer via un bouton à l'intitulé sans ambiguïté
• Un accusé de réception sous forme textuelle doit être envoyé

Le dernier point détermine l'architecture. Une résiliation est une déclaration unilatérale et prend effet à sa réception. Elle doit donc toujours être enregistrée et confirmée, quelle que soit la personne dont elle émane.

Le formulaire ne doit jamais te refuser

C'est là que l'approche évidente a failli nous coûter une erreur.

L'approche évidente : n'accepter la résiliation que si l'ID du serveur et l'e-mail correspondent à un abonnement actif. Cela semble raisonnable, et c'est faux à double titre.

D'abord, cela bloquerait un vrai client qui fait une faute de frappe dans son e-mail ou indique une autre adresse. Sa résiliation n'aurait pas été reçue, l'abonnement se renouvelle, et il détient la preuve qu'il a essayé.

Ensuite, et c'est la partie la plus désagréable : le message d'erreur lui-même serait une réponse. Quiconque reçoit « aucun abonnement trouvé » apprend que ce serveur ne paie pas. Un ID de serveur Discord n'est pas un secret, n'importe quel membre peut le lire. Le formulaire deviendrait un outil pour sonder les serveurs des autres.

La solution sépare deux choses qui semblent n'en faire qu'une :

	Condition
Réception de la déclaration	inconditionnelle, toujours enregistrée et confirmée
Exécution de la résiliation	uniquement si l'e-mail saisi correspond à l'acheteur enregistré

Tout le reste atterrit dans une file d'attente et est examiné par un humain. C'est permis parce que l'article 312k, paragraphe 2, autorise expressément à demander des informations d'identification. Seule une connexion préalable est interdite.

Pour la même raison, la réponse publique ne peut indiquer la date de fin qu'une fois l'identité confirmée. Sinon, la confirmation redevient un oracle.

La rétractation qui exige volontairement une connexion

Juste à côté se trouve une fonctionnalité que nous avons construite à l'inverse : la rétractation avec remboursement au prorata se trouve derrière une connexion.

Ce n'est pas une contradiction. L'article 312k couvre la résiliation, pas la rétractation, et il n'existe aucune obligation de proposer un formulaire de rétractation en ligne tant que la voie informelle reste ouverte. La différence, c'est la conséquence : une résiliation agit sur l'avenir, un remboursement déplace de l'argent maintenant, et on ne peut pas le récupérer.

Trois règles en découlent, que nous n'assouplissons pas :

Pas de motif obligatoire. L'article 355, paragraphe 1, accorde la rétractation expressément sans avoir à donner de motif. Le champ est facultatif et doit le rester, aussi tentant qu'un champ obligatoire puisse être pour les statistiques.

Après 14 jours, seule la voie automatique est refusée, jamais la déclaration. Le délai s'étend jusqu'à douze mois et quatorze jours si le client n'a pas été correctement informé. Un « trop tard » général pourrait donc être faux.

La protection contre un double paiement est pessimiste. Le marqueur est posé avant l'exécution du remboursement. Si le remboursement échoue ensuite, le marqueur reste et un humain prend le relais. Payer deux fois est la seule issue qu'on ne peut pas réparer.

Un MP Discord n'est pas un support durable

L'article 312f, paragraphe 3, exige une confirmation du contrat sur un support durable, et elle doit reproduire le consentement donné.

Nous avons d'abord envoyé un message privé Discord, parce que c'est le canal où nos clients se trouvent de toute façon. Cela ne suffit pas. Un MP vit sur une plateforme que nous ne contrôlons pas, et il n'est ni conservable ni inaltérable au sens où l'entend la disposition.

Un e-mail a donc été ajouté, et avec lui une dépendance inconfortable : si les identifiants de messagerie ne sont pas définis, l'envoi écrit seulement un avertissement dans le log et l'obligation n'est pas remplie. Une obligation légale qui dépend d'une variable d'environnement est une situation dont il vaut mieux être conscient.

Pas de TVA, et cela doit se lire de la même façon partout

AlphaCloud est une petite entreprise au sens de l'article 19 de la loi allemande sur la TVA. Les prix sont des prix finaux, la TVA n'est jamais affichée.

Cela ressemble à une note de bas de page et c'est en réalité une tâche de cohérence à travers de nombreux endroits : la page des tarifs, la fenêtre de paiement, les conditions, la politique de confidentialité, le pied de page des factures et la configuration chez le prestataire de paiement doivent tous dire la même chose. Un « hors TVA » est resté longtemps quelque part, et il était tout simplement faux.

Et l'IA

Depuis août 2026, les obligations de transparence du règlement européen sur l'IA s'appliquent pleinement. Toute personne qui parle à un système d'IA doit pouvoir le reconnaître, au plus tard lors de la première interaction.

La phrase la plus importante pour nous issue de cet examen : une page juridique dans le pied de page ne suffit probablement pas. L'information doit avoir lieu là où l'interaction a lieu, donc dans le message Discord lui-même. C'est pourquoi notre support IA dans les tickets se présente de lui-même et dispose d'un bouton visible pour le désactiver. Notre évaluation détaillée se trouve sur transparence de l'IA.

Le fil conducteur

Les quatre exemples ont la même forme : l'obligation ressemblait à un texte et était en réalité une exigence sur la structure. Une connexion au mauvais endroit, un message d'erreur qui en révèle trop, une confirmation dans le mauvais canal, un ordre qui permet un double paiement.

Nous lisons donc désormais les textes juridiques comme une spécification, et nous vérifions aussi dans l'autre sens : le code fait-il vraiment ce que disent nos conditions ? Sur exactement cette question, nous avons trouvé deux vrais écarts, et un article séparé leur est consacré.