Cape Coast Logbook
Un site one-page et un petit espace d'administration en autonomie qui transforment un programme de 16 semaines à l'étranger en carnet de bord partagé pour une promotion de 32 étudiants ouest-africains.
Projet solo : conception, design, développement, déploiement
WASCAL Cape Coast réunit 32 étudiants francophones de 8 pays d'Afrique de l'Ouest pour un programme d'immersion en anglais de 16 semaines à Cape Coast, au Ghana. Le site est le point de repère unique de la promotion : un one-page qui raconte le programme (pourquoi il existe, le Club d'anglais, les activités, les huit soirées-pays) et un carnet de bord de ce que le groupe a réellement vécu, semaine après semaine. Un court sondage a recueilli le logement, le niveau d'anglais, les préférences d'activités et les talents de chacun, pour que les organisateurs constituent les groupes d'activités et planifient la rotation des soirées-pays. Un espace d'administration protégé par mot de passe permet au Club d'anglais de tenir le carnet, les galeries photo et le sondage à jour sans toucher au code. Le site tourne en production sur un simple hébergement mutualisé, sans étape de build et sans serveur à maintenir.
Le problème
Une nouvelle promotion arrive à Cape Coast chaque année sans rien pour tenir l'expérience ensemble : pas de calendrier commun, pas d'endroit pour voir qui compose le groupe, aucune trace de ce qui s'est passé. L'information vit dans des messages éparpillés et se perd au fil des semaines. Les organisateurs n'avaient pas non plus de vision structurée du groupe pour bâtir les activités et les soirées-pays.
L’approche
J'ai construit un site one-page qui raconte le programme et sert en même temps de carnet de bord vivant, adossé à un petit espace d'administration que le Club d'anglais gère lui-même. L'hébergement était fixé d'avance à un mutualisé basique, sans Node ni VPS : j'ai donc réécrit un premier prototype Node en application Laravel et gardé un front en HTML, CSS et JavaScript simples, sans étape de build. Le sondage, les galeries et la chronologie s'éditent depuis l'administration, donc le site reste à jour sans développeur.
Le résultat
- La promotion dispose d'une seule adresse pour tout le programme, au lieu de messages éparpillés.
- Les 32 étudiants ont répondu au sondage, donnant aux organisateurs une vision complète pour former les groupes d'activités et programmer les huit soirées-pays.
- Le Club d'anglais met à jour le carnet, les galeries et le sondage lui-même, sans développeur dans la boucle.
- Tourne en production sur un hébergement mutualisé, sans pipeline de build ni coût serveur récurrent.
Fonctionnalités clés
- One-page qui raconte le programme : le Club d'anglais, les quatre familles d'activités, les huit soirées-pays, le festival de clôture.
- Carnet de bord : le séjour raconté étape par étape, dans l'ordre où ça s'est passé, écrit par le Club d'anglais.
- Galeries photo par thème, chacune avec un lien vers l'album Drive pleine résolution de l'activité.
- Sondage de groupe : logement, niveau d'anglais, préférences d'activités et talents, en formulaire à quatre étapes, avec un interrupteur pour l'ouvrir ou le fermer.
- Administration en autonomie : le Club d'anglais édite le carnet, les galeries et le sondage, et exporte les réponses en CSV, le tout derrière un seul mot de passe.
- Fonctionne sur n'importe quel hébergement basique : pas de build, pas de Node, pas de serveur à maintenir.
- Identité visuelle ouest-africaine : palette inspirée du kente, bandeau de drapeaux animé, animations qui respectent les préférences de mouvement réduit.
Ingénierie — Architecture, décisions et compromis
Architecture
Le front, c'est trois pages HTML statiques servies en fichiers par Laravel, partageant un fichier CSS et un fichier JavaScript en module ES à la racine web, sans aucun bundler. Le back Laravel expose une petite API JSON (sondage, galeries, étapes du parcours, admin) et un unique rôle super-admin par session, protégé par un mot de passe. Le contenu éditable par le Club d'anglais vit en base (journey_stages, gallery_albums, gallery_photos, settings clé-valeur) ; les référentiels serveur et les règles de validation sont dans un fichier de config, en miroir du module partagé du front. MySQL en production, SQLite en développement, avec un SQL gardé portable entre les deux. Un .htaccess racine réécrit chaque requête vers le dossier public/ de Laravel tout en bloquant le code source et les secrets, pour que tout le dépôt puisse être téléversé sur un mutualisé où la racine web est la racine du dépôt.
Défis d’ingénierie
- Hébergement imposé, sans Node. La cible était un mutualisé basique : pas de VPS, pas de process Node, pas de serveur de build. J'ai réécrit le prototype Node/Fastify d'origine en Laravel et figé les URL d'API pour qu'elles correspondent exactement aux anciennes, pour que le front vanilla existant continue de tourner sans une seule modification.
- Pas d'étape de build, volontairement. Les pages embarquent du JavaScript inline, qui entre en conflit avec la syntaxe
{{ }}de Blade : elles sont donc servies en fichiers bruts plutôt qu'en templates compilés. Les assets partagés sont de simples fichiers à des chemins fixes. - Le programme s'est réorganisé en cours de route. Une version antérieure avait un système de comités complet (codes d'accès par comité, équilibrage manuel, PDF de rotation imprimable). Quand le programme a abandonné les comités, j'ai retiré toute cette couche via des migrations et l'ai remplacée par un carnet de bord chronologique plus simple.
Décisions techniques
- Laravel plutôt que garder Node. L'hébergement ne pouvait pas faire tourner Node : un framework PHP sur mutualisé avec MySQL était la seule voie qui rentrait dans la contrainte sans louer de serveur.
- La parité de contrat d'API comme stratégie de migration. Réécrire le serveur en gardant exactement les mêmes URL d'API et les mêmes messages de validation a évité de re-tester et re-livrer le front.
- Le contenu en base plutôt que des redéploiements. Le carnet, les galeries et l'interrupteur du sondage s'éditent depuis l'admin, parce que ceux qui tiennent le site à jour sont le Club d'anglais, pas un développeur.
- SQLite en dev, MySQL en prod. Même schéma via les migrations Eloquent, pas de SQL spécifique à un moteur : le travail local ne demande aucune installation et la prod reste sur le MySQL de l'hébergeur.
Stack
- Laravel 13
- PHP 8.3
- MySQL
- SQLite
- JavaScript (vanilla)
- HTML/CSS
- Apache / .htaccess
Projet solo : conception, design, développement, déploiement — Projet personnel, réalisé pour la promotion WASCAL Cape Coast 2026 (dont je faisais partie) (2026)