En terminale, j'ai ouvert un éditeur de texte et décidé de coder mon propre agenda plutôt que d'en utiliser un. Trois ans plus tard, il tourne encore.
Le Contexte
agendDAY n'est pas né dans un cours. En terminale, je voulais m'organiser et j'ai décidé de construire l'outil plutôt que d'en utiliser un. À l'époque, je partais de zéro : je ne savais pas comment PHP communique avec MySQL, ce qu'est une session, ni pourquoi une requête SQL peut être dangereuse. J'ai tout découvert en cassant des choses.
Le projet a ensuite évolué tout au long de mon BTS SIO SLAM. Chaque compétence acquise en cours trouvait un terrain d'application immédiat sur agendDAY : les sessions PHP ont donné lieu à l'authentification, les variables CSS au thème clair/sombre, les fonctions de hachage à la gestion sécurisée des mots de passe.
Hébergé sur OVH, serveur Apache, base MySQL. Pas de framework au départ parce que je n'en connaissais pas.
Le Produit
Ce n'était pas le plan initial. Au départ, agendDAY affichait des dates et c'était tout. Chaque fonctionnalité a été ajoutée quand j'avais les outils pour la faire correctement : le CRUD des événements, puis l'authentification, puis le thème clair/sombre, puis les rappels par mail.
J'ai aussi conçu une landing page complète hero avec aperçu interactif du calendrier, section fonctionnalités, témoignages et call-to-action. Pas parce que c'était demandé, mais parce que je voulais que ça ressemble à un vrai produit. C'est là que j'ai commencé à penser à l'utilisateur avant de penser au code.
Le Calendrier
Afficher un calendrier mensuel paraît simple jusqu'à ce qu'on s'y attaque. Premier problème : quel jour de la semaine tombe le 1er du mois ? Ensuite : comment décaler les cases vides en début de grille ? Comment gérer février ? Comment naviguer entre les mois sans recharger la page ?
J'ai construit la grille entièrement en JavaScript création dynamique des nœuds DOM, calcul des offsets, mise en évidence du jour actif. Le panneau latéral se met à jour à chaque clic sur une case et récupère les événements du jour depuis la base.
CRUD & Modales
Ajouter un événement, ça veut dire : ouvrir une modale sans recharger, valider côté client, envoyer une requête PHP, écrire en base, renvoyer une réponse, mettre à jour l'interface. Sur le papier c'est linéaire. Dans la pratique, j'ai écrit des dizaines de variantes avant d'avoir quelque chose de propre.
Le point critique a été la gestion des données par utilisateur. Un événement appartient à un compte précis ça paraît évident, mais c'est là que j'ai compris pourquoi on ne doit pas laisser le client envoyer son propre ID dans les requêtes, et pourquoi les requêtes préparées existent.
Les Versions BTS
En BTS, j'ai ajouté l'inscription et la connexion. Ça impliquait de gérer les sessions PHP correctement, de hacher les mots de passe en bcrypt et de ne pas laisser un utilisateur accéder aux données d'un autre.
Le thème clair/sombre m'a introduit aux variables CSS. Un attribut sur le <body>, des propriétés qui cascadent, et un choix mémorisé en localStorage.
Les rappels par mail, envoyés via PHPMailer, ont introduit une logique différente : une tâche déclenchée côté serveur à un moment précis, indépendamment de ce que fait l'utilisateur. Mon premier contact avec la notion de traitement asynchrone.
Bilan
La vraie difficulté de ce projet n'était pas technique c'était de progresser sans repère. Quand ça bloque, il n'y a personne à côté pour pointer la ligne de code. On fouille, on teste, on casse autre chose en corrigeant, et on recommence. Ça m'a pris du temps mais j'ai compris ce que je faisais.
agendDAY est encore en ligne aujourd'hui, avec du code écrit à plusieurs époques. On peut voir dedans les traces de chaque apprentissage. Je n'en ai pas honte : c'est la preuve que le projet a servi à quelque chose.