Sécurité, maintenance et risques technologiques

Site GOBEL — Document à l'intention du board

Association Belge du Jeu de Go
Juin 2026

1. Sur le code généré avec assistance IA

L'IA a-t-elle tout écrit ? Peut-on lui faire confiance ?

L'IA (Claude, développé par Anthropic) a servi d'outil de développement accéléré, pas de décideur. Chaque fonctionnalité a été :

1. Spécifiée par Yannick Kuy (cahier des charges, choix d'architecture, décisions de conception)

2. Générée par Claude sous supervision directe

3. Relue et validée par Yannick avant chaque commit

4. Testée manuellement (et pour le système ELO, par 47 tests automatisés)

L'IA ne déploie rien de manière autonome. Chaque ligne de code en production a été approuvée par un humain. Le code produit est du TypeScript standard, lisible par n'importe quel développeur web, sans dépendance à Claude pour la maintenance future.

Comment est assuré le contrôle du code ?

• Git (GitHub) : historique complet de chaque modification avec date, description et auteur

• Chaque commit est accompagné d'un message expliquant pourquoi le changement a été fait

• Le code est hébergé sur un dépôt privé GitHub — accessible à tout développeur mandaté ultérieurement

2. Sécurité

2.1 Protection des comptes membres

MesureDétailMots de passeHachés avec bcrypt (facteur 12) — jamais stockés en clairTentatives échouéesBlocage automatique après 5 échecs, déverrouillage après 15 minutesSessionsJWT signé côté serveur, expiration automatiqueRéinitialisationLien par email, valide 1 heure seulementComplexité imposée8 caractères minimum, majuscule + chiffre obligatoires

2.2 Protection des données personnelles

• Données sensibles (email, téléphone, adresse, date de naissance) stockées dans Supabase (PostgreSQL sur AWS eu-central-1, en Europe)

• Vercel (serveur web) ne stocke jamais les données — il exécute le code et passe les requêtes à Supabase

• Transit : HTTPS imposé sur toutes les pages, les données ne circulent jamais en clair

• Clés secrètes stockées exclusivement dans les variables d'environnement Vercel — jamais dans le code source, jamais dans Git

2.3 Contrôle des accès (principe du moindre privilège)

Chaque action sur le serveur vérifie le rôle de l'utilisateur connecté. Un PRESIDENT ne peut agir que sur les membres de son club. Un MEMBER ne peut modifier que son propre profil. Il est impossible d'élever ses propres droits.

2.4 RGPD

• Demande de suppression accessible depuis le profil de chaque membre

• Anonymisation complète : le nom devient "Joueur Anonyme-xxx", l'email est remplacé par une adresse aléatoire, toutes les données personnelles sont effacées

• L'historique sportif (parties, résultats) est conservé — obligation d'intégrité sportive

• Page de politique de confidentialité disponible sur le site (/privacy)

2.5 Ce qui n'est PAS couvert (périmètre délibéré)

• Pas d'authentification à deux facteurs (2FA) — jugé disproportionné pour une fédération de go, mais implémentable si requis

• Pas d'audit de sécurité externe — recommandé avant une mise en production grand public

3. Maintenance

3.1 Qui peut maintenir ce site ?

N'importe quel développeur web fullstack familier avec :

• Next.js (React) — le framework le plus populaire au monde pour les applications web, utilisé par des milliers d'entreprises

• PostgreSQL — base de données relationnelle standard

• TypeScript — JavaScript avec typage statique

Le code ne contient pas de technologies exotiques ou propriétaires. Un développeur compétent peut le reprendre en quelques jours de lecture.

3.2 Mises à jour de sécurité

Les dépendances npm (librairies) peuvent recevoir des correctifs de sécurité. La procédure est :

npm audit          # identifier les vulnérabilitésnpm update         # mettre à jour les dépendances mineures

Recommandé : vérifier mensuellement, surtout pour NextAuth (authentification) et Prisma (accès DB).

3.3 Modifications de contenu sans développeur

Le bureau peut modifier sans toucher au code :

• ✅ Actualités, événements, pages du site

• ✅ Menu de navigation (sidebar)

• ✅ Photos de clubs et tournois

• ✅ Cotisations, droits de vote des membres

• ✅ Résultats de tournois

Nécessite un développeur :

• Nouvelles fonctionnalités

• Modifications du schéma de base de données

• Changements d'infrastructure

3.4 Base de données

Les migrations de base de données sont versionnées dans le code (prisma/migrations/). Chaque modification du schéma est tracée et reproductible. Il est possible de revenir en arrière sur n'importe quelle version.

3.5 Sauvegardes

Supabase effectue des sauvegardes quotidiennes automatiques (point-in-time recovery sur 7 jours en plan gratuit). En cas de problème grave, les données peuvent être restaurées à n'importe quel état des 7 derniers jours.

4. Risques technologiques

4.1 Vercel (hébergement)

4.1 Vercel (hosting)

Zone grise légale : le plan Hobby de Vercel est formellement réservé aux projets non commerciaux. Une ASBL percevant des cotisations est dans une zone grise. Vercel ne vérifie pas activement, mais le passage au plan Pro (20 $/mois) éliminerait ce risque théorique.

4.2 Supabase (base de données)

4.3 Next.js (framework web)

Next.js est développé par Vercel et utilisé par des entreprises comme TikTok, Twitch, et des centaines de milliers de projets. Le risque d'abandon est quasi nul. Les mises à jour majeures (tous les ~18 mois) nécessitent une migration, généralement bien documentée.

4.4 Dépendance à l'assistant IA pour la maintenance future

Le code ne dépend pas de Claude pour fonctionner ou être maintenu. Claude a été un outil de développement, comme un IDE ou un linter. Un développeur humain peut reprendre le projet sans jamais utiliser d'IA.

Cela dit, utiliser un assistant IA pour des modifications futures est parfaitement envisageable — c'est désormais une pratique courante dans l'industrie, y compris dans des contextes critiques.

4.5 Continuité si le développeur actuel est indisponible

Court terme (< 1 mois) : le site fonctionne seul, aucune intervention requise pour le fonctionnement quotidien.

Moyen terme : n'importe quel développeur Next.js peut reprendre le projet. Les commits sont commentés et les fonctions critiques (ELO, anonymisation, cotisations) sont documentées. Le reste du code est peu commenté — un rapport technique décrivant l'architecture globale est prévu pour combler cette lacune.

Transfert de responsabilité nécessite :

1. Accès au dépôt GitHub (invitation à transférer en < 5 minutes)

2. Accès au dashboard Vercel (invitation par email)

3. Accès au projet Supabase (invitation par email)

4. Variables d'environnement (fichier .env transmis de manière sécurisée)

5. Coûts actuels et projection

Pour une fédération de ~500 membres, les limites gratuites ne seront pas atteintes dans les 2-3 prochaines années. Le scénario de dépassement le plus probable est le stockage Supabase si les uploads de photos de clubs/tournois deviennent nombreux.

Option : migration vers un serveur persistant

L'architecture actuelle sur Vercel utilise des fonctions serverless : le serveur se "réveille" à chaque requête après quelques minutes d'inactivité, causant une latence de 500ms à 2 secondes sur la première visite. Ce comportement est inhérent au modèle serverless et ne peut pas être corrigé sans changer d'hébergeur.

Pour une expérience utilisateur fluide (< 100ms sur toutes les pages), une migration vers un serveur persistant est envisageable :

OptionPrixLatenceEffort de migrationVercel (actuel)0 €/an500ms–2s (cold start)—Railway~5 $/mois100–200ms (sans cold start)1–2 joursRender~7 $/mois100–200ms (sans cold start)1–2 jours

Supabase reste inchangé dans les deux cas — seul l'hébergeur du site change. La migration est réversible à tout moment.

6. Recommandations pour le board

1. Confier la maintenance au développeur actuel (Yannick Kuy) via une convention de maintenance annuelle. En tant qu'auteur du projet, il connaît l'intégralité du code et peut intervenir rapidement sur tout bug ou évolution. Une rémunération mensuelle modeste (à négocier) garantit la continuité du projet sans recourir à un prestataire externe qui devrait d'abord monter en compétence sur le code. C'est la solution la plus efficace et la moins coûteuse pour la fédération.

2. Documenter les accès : qui a les credentials Vercel, Supabase, GitHub, Resend — et prévoir une procédure de transmission en cas de changement, indépendamment de qui assure la maintenance.

3. Effectuer un audit de sécurité (outil gratuit OWASP ZAP) avant l'ouverture au grand public.

4. Décider de l'hébergement : rester sur Vercel (gratuit, cold start de ~1s) ou migrer vers Railway (~5 $/mois, navigation fluide). Voir section 5.

5. Prévoir un budget annuel couvrant infrastructure + maintenance :

Document rédigé en juin 2026 — gobel-site