Après 10 ans au service de la communauté 42, S42 ferme ses portes

Je vois que tu as un programme de sponsorship actif sur github et j'ai cru comprendre que tu avait un système de cosmétique. Maintenant que le projet est hébergé, il n'est pas du tout nécessaire de maintenir ce programme et ces options de sponsoring. Peux-tu faire le nécessaire pour les supprimer au plus vite?

La première est que nous ne pouvons pas prendre le risque de te laisser la propriété du domaine, cela laisse te laisse une possibilité de modification des entrée DNS

La deuxième est purement et simplement un besoin légal de protection de la marque 42. Maintenant que l'app est offciellement host par 42 te laisse le domaine signifie accepter le risque d'avoir des sous-domaines qui n'ont aucun rapport avec 42 et sa pédagogie et c'est un risque que nous ne pouvons pas prendre.

Je voulais faire un récap des actions à suivre pour être bien sûr qu'on partage bien la même roadmap sur les actions à suivre :
- Récupération du domaine par 42 et bascule des DNS
- Changement de la clé API
- Récupération des accès en production
- Récupération des accès admins

J'aimerais basculer le domaine et les DNS avant le 30 janvier. Est-ce que ça te semble réaliste ?

Bonjour Sebastien, désolé du temps de réponse, mes semaines sont quelques peu chargées.

Pour faire suite à ta demande, je souhaitais revenir sur certains points essentiels pour garantir une gestion optimale et éviter d’éventuels blocages :

Points soulevés :

1. Récupération des clés API :
   Une rotation des clés doit etre effectuée chaque année, inclut la gestion des webhooks (maintien, creation, rotation des secrets, suppression), endpoints et configurations associées.
   En déléguant cette responsabilité, vos équipes devront intervenir régulièrement, ce qui représente une charge supplémentaire.
2. Gestion des accès en production et administrateurs :
   Le transfert complet des accès impliquerait que toutes les interventions (modifications, mises à jour ou corrections, demande étudiante relatif a la RGPD, intervention) doivent passer par vos développeurs.
   Cela signifie que, pour chaque besoin technique, il faudra mobiliser vos ressources, ce qui risque d’alourdir votre organisation.
3. Disponibilité des ressources :
   Étant donné la vitesse d’échange que nous avons constatée ces quatre dernières années, des deux cotés, il me paraît peu réaliste d’imaginer qu’un développeur pourra être disponible à tout moment pour répondre aux besoins du projet ou des étudiants.

Proposition :

Afin de maintenir une gestion efficace et fluide, je propose de formaliser la situation actuelle par un contrat écrit et signé, qui clarifierait les responsabilités et protégerait les deux parties.
Ce contrat pourrait inclure :

• Le fait que je conserve la gestion complète du domaine, des accès techniques et des opérations associées.
• Vos droits en tant qu’organisation, de surveiller la bonne utilisation des données, d'assurer un hebergement et une protection des données, tout en me permettant de continuer à maintenir le projet.
• Décrire les points de sécurité que chaque partie se doit de respecter, comme un Accord de Licence et de Confidentialité (ALC). 

Cela garantit que le projet reste fonctionnel sans impact sur les équipes tout en cadrant légalement notre collaboration.

Je reste à ta disposition pour affiner cette proposition.

Cordialement,
Atom

(...)

Le renouvellement des clés n'est pas un problème pour nous.

Concernant les mises à jour, le fonctionnement que nous souhaitons avoir est le même que pour n'importe quel outil open-source. Les bugs sont remontés sur le git du projet. les membres du projet crée une nouvelle version et nous la déployons selon notre planning. Je t'accorde que fonctionnement va être un peu plus lent que le processus actuel mais je pense que c'est un mal nécessaire .

Enfin pour la partie administrateur je n'avais pas pas imaginé que cela prendrait tant de temps que ça. Combien de temps consacres-tu généralement à l'administration ?

Pour conclure, nous avons vraiment besoin de récupérer le contrôle sur le domaine et l'application. Je ne pense pas qu'un fonctionnement hybride ou tu reste administrateur de l'appli soit une bonne idée. Cela maintient un flou autour des responsabilités envers les étudiants. Pour ce faire, nous avons besoin d'initier un transfert du domaine et de tous les éléments cités dans mon précédent e-mail.

(...)

(...)

Sans réponse de ta part et avancement concret sur ces sujets dans les plus brefs délais, nous serons malheureusement contraints de prendre la décision de couper le projet et de supprimer les webhooks custom qui sont configurés sur ton compte à partir du 18 Avril.

(...)

Enfin, concernant le nom de domaine s42.app, l'article 24 du règlement intérieur prévoit que "Tout dépôt / enregistrement / utilisation par un Utilisateur, candidat ou étudiant de 42, d'un signe distinctif composé du nombre "42", notamment à titre de marque, dénomination sociale et noms de domaines, qui porterait atteinte aux droits antérieurs de l’Association 42, est expressément interdit. Tout manquement à cet engagement exposerait le contrevenant à des sanctions disciplinaires ainsi qu’à des poursuites civiles et/ou pénales."

Merci pour ton message et pour la reconnaissance du travail accompli depuis près de 10 ans avec le projet S42. J’en mesure l’impact au sein du réseau et l’implication constante qu’il a demandé depuis sa création.

Je tiens néanmoins à formuler une réponse claire et structurée aux propositions et arguments avancés, sur les plans techniques, réglementaires et juridiques.

1. Sur les webhooks et la collecte de données

Oui, les webhooks transmis peuvent inclure certaines données sensibles, comme les numéros de téléphone. Cela dit, aucune de ces données n’est utilisée ou traitée dans le code de S42. Elles sont explicitement ignorées, et auditablement absentes de toute fonctionnalité exposée. Par ailleurs, les données sont stockées sur l’infrastructure de 42, ce qui implique que vous restez responsable du traitement au sens du RGPD. Le code étant Open-Source il reste auditable par n'importe quel personne ou entité !

Les données effectivement utilisées (notamment les événements de localisation) sont strictement équivalentes à celles accessibles via l’API REST, ce que de nombreux autres projets étudiants exploitent déjà via polling, parfois en contournant les limites de quota. 

2. Sur l’accès à l’API et le respect des CGU

J’utilise l’API dans le cadre de mon compte alumni actif, en accord avec les CGU. Le projet respecte l’ensemble des contraintes techniques et réglementaires, y compris celles imposées par la charte de l’API. En cas de doute, je reste évidemment ouvert à corriger toute anomalie dans un délai raisonnable.

Je rappelle que S42 est à ce jour le seul projet à avoir systématiquement respecté les demandes de la DPO, notamment la validation explicite des campus avant toute activation, ce qui a limité sa diffusion contrairement à d’autres projets non encadrés.

3. Sur le nom de domaine et l’article 24 du règlement intérieur

Le domaine s42.app est enregistré par mon organisation, Atomys. Il ne contient aucun visuel, logo, slogan ou signe distinctif de 42, et ne peut être confondu avec un service officiel.
L’article 24 du règlement intérieur ne s’applique qu’aux étudiants dans un cadre disciplinaire interne. Il ne constitue ni une base légale pour une demande de transfert, ni un droit exclusif sur toute combinaison contenant “42”.

Aucune atteinte réelle ni usage commercial n’est établi. Le nom est utilisé dans un cadre strictement open source, pédagogique et bénévole, sans aucun préjudice porté à 42, ce qui respect le dit règlement.

4. Sur les options proposées

Je prends note des deux options que vous évoquez et propose une troisième voie équilibrée.

• Option 1 : Reprise complète par 42
  Je ne suis pas favorable à cette option, car elle impliquerait la cession totale d’un projet que j’ai conçu, maintenu, fait évoluer, financé et sécurisé depuis près de 10 ans. Je refuserai d’être rétrogradé au rang de contributeur occasionnel, sans pouvoir décisionnel, sur ce que j’ai porté seul pendant toutes ces années.
  Si 42 souhaite assumer les responsabilités juridiques du traitement, cela peut être fait via un accord écrit bilatéral, clair et signé, sans exiger la cession du projet.
• Option 2 : Hébergement par 42, administration par mes soins
  C’est la solution la plus raisonnable.
  L’hébergement resterait assuré par 42, garantissant la sécurité des données et la conformité RGPD.
  Je conserve la responsabilité du développement, des évolutions, et de la gouvernance technique du projet.
  Ce modèle a été mis en place récemment, à notre initiative partagée, pour répondre à vos attentes. Avant cela, j’assurais l’intégralité de la stack, sans incident, depuis le lancement du projet.
  Je suis tout à fait ouvert à formaliser cette relation dans un cadre contractuel clair : 42 comme hébergeur et responsable du traitement, moi comme gérant technique du project.
• Option 3 : Fin du projet S42
  En l’absence d’accord équilibré, je mettrai fin au projet avec une communication publique. Je refuse de céder un outil que j’ai construit avec rigueur, éthique et respect du RGPD, à une structure qui me le retirerait sans garantie de continuité, de transparence ou de respect du modèle mis en place suite à un accord clair avant migration. 
  À l’origine, j’ai proposé ce partenariat pour sécuriser les données étudiantes, car j’étais l’auteur des webhooks, au fait des contraintes RGPD en tant qu’ancien staff. Aujourd’hui, je suis le seul projet pénalisé pour avoir respecté scrupuleusement ces règles.

5. Modalités de communication

Pour des raisons de traçabilité juridique, je vous demande expressément que toutes les discussions aient lieu par écrit (email). Je ne participerai à aucun échange oral sans trace, ni à des réunions sans cadre préalable.

Dans l’attente d’un retour clair et formalisé, je reste à disposition pour avancer dans le respect mutuel du travail accompli et des engagements pris.

Cordialement,
Atom
Créateur et mainteneur de S42.

PS: Bravo pour l'ouverture de 42Up.

Ceci étant dit, si comme tu l'indiques, les webhooks sont si peu importants pour ton application et que leur désactivation ne pose pas de problèmes particulier, cela semble régler tous nos problèmes et simplifier drastiquement la situation.

=> Pas de webhook qui traite des données étudiants signifie aucun traitement sortant du cadre autorisé par 42

=> Plus besoin d’encadrer ce traitement, et donc plus besoin de gérer l'hébergement, l'administration, ni même le domaine s42.app.

Je suis donc ravi de répondre positivement à ta demande en te laissant la responsabilité de l'hébergement et de l'administration de S42.

Nous allons donc procéder à la désactivation des webhooks suivants en date du 24 Juin. (...)

À travers cette décision unilatérale, il devient évident que le partenariat proposé par 42 n’avait pas pour but de faire perdurer un projet open source utile à la communauté, mais de répondre temporairement à un besoin interne en matière de reporting et de présence.

Le fait que, dès la première difficulté soulevée, vous décidiez de vous désengager complètement du projet, sans même proposer de solution contractuelle

Je constate aujourd’hui que ce dialogue est rompu à sens unique, et que la continuité du projet ne vous importe pas tant que vos obligations légales ou opérationnelles sont contournées.

Nous te confirmons que les services d’hébergement ainsi que les Webhooks permettant l’accès à des informations privées seront désactivés le 24 juin à 11h30.

Par ailleurs, nous te confirmons que les accès ont bien été rétablis sur la partie Kubernetes GCP. Concernant tes droits administrateur sur l'application, ils sont toujours actifs, même si tu n'y accèdes pas actuellement. Tu es donc libre de choisir la date de migration.

Nous ne te fournirons pas de certificat de fin de partenariat, dans la mesure où aucun contrat de partenariat formel n’a jamais été établi. Il s’agissait d’une tolérance accordée à une époque par 42, et non d’un partenariat structuré. Cette situation doit désormais être revue.

Tu restes naturellement libre de communiquer sur la fin de ton projet. Toutefois, nous attirons ton attention sur l’emploi du terme « rupture », qui est inapproprié : en l’absence de partenariat officiel, il ne peut être question de rupture.

Nous sommes par ailleurs toujours en attente de l’attestation de destruction des données personnelles, mentionnée dans les précédents échanges avec Sébastien.

Nous souhaitons également te rappeler plusieurs éléments relatifs à la non-conformité RGPD de ton site :

• La politique de confidentialité n’est pas conforme aux articles 13 et 14 du RGPD, malgré l’alerte déjà remontée par mail le 5 novembre 2024. De plus, les Terms of Use et la Politique de confidentialité sont toujours en statut "draft".
• L’accès aux données via les Webhooks n’est pas conforme à l’article 5 du RGPD : des données personnelles restent accessibles alors que, selon ton précédent mail, elles ne sont ni traitées, ni utilisées, ce qui constitue une violation du principe de minimisation des données.
• Dans ce contexte, se prévaloir d’une conformité RGPD est particulièrement surprenant, d’autant que la non-conformité du site a déjà été signalée sans prise en compte desdites remontées, et que des plaintes d’étudiants nous sont également parvenues.

Enfin, je souhaite rappeler que cela fait maintenant plus de huit mois que nous sommes en discussion sur ces sujets, dans une volonté constante de trouver une issue satisfaisante. Force est de constater qu’aucune issue concrète n’a pu être dégagée à ce jour et il me semble malheureusement que les affirmations récentes et le ton adopté ne soient pas signe d'une volonté de trouver des solutions ensembles.

Nous restons dans l’attente du document signé relatif à la suppression des données.