Optimisation de la landing page Cercle des Ops
Alexis optimise une landing page PHP en déplaçant les appels API Stripe lents du serveur vers le client JavaScript, puis implémente un formulaire de préqualification modal, transformant 5 secondes de chargement en expérience fluide.
À propos de cette session
Alexis débute la session en identifiant un problème critique sur sa landing page : les appels API Stripe pour vérifier les places restantes se font au chargement PHP, provoquant 5 secondes de délai. Le cache qu'il avait implémenté devient inutile avec Varnish en amont.
Il demande à Claude Code de réarchitecturer le système en déplaçant les appels vers JavaScript côté client. Claude propose un plan détaillé avec création d'endpoint backend sécurisé et chargement asynchrone frontend. Alexis accepte l'implémentation.
Premier problème : Claude oublie de supprimer l'ancien code PHP, la page reste lente. Alexis découvre l'erreur en testant sans cache, illustrant comment les caches masquent les problèmes. Après correction, Claude teste lui-même l'API avec curl, comportement qu'Alexis apprécie.
Les appels restent lents (10 secondes). Alexis demande des optimisations. Claude réduit la période de recherche des données Stripe et implémente un cache adaptatif selon l'heure, un fallback sur erreurs et des valeurs par défaut. Performance réduite à 1 seconde.
Deuxième fonctionnalité : Alexis veut ajouter un formulaire de préqualification avant paiement, inspiré de son système existant sur Tally. Il copie-colle le contenu et demande un modal overlay avec validation des niveaux débutant/intermédiaire.
Claude implémente un système complet : modal responsive, stockage JSON local, rate limiting, validation, redirection avec paramètres pré-remplis vers Stripe. Alexis teste et découvre des détails non demandés comme l'email pré-rempli et l'ID de référence.
Problème de sécurité détecté : le fichier JSON est accessible publiquement. Alexis demande protection via .htaccess. Claude sécurise et teste l'accès.
Claude propose des améliorations supplémentaires (animations, tracking, scoring) qu'Alexis juge superflues. Il sélectionne uniquement quelques optimisations UX mineures.
Session conclue avec versionning Git et déploiement en production. Alexis note l'importance de vérifier les fichiers avant commit pour éviter les fuites de données.
Points clés
- Les caches masquent les problèmes de performance et peuvent retarder la détection d'erreurs critiques
- Il faut toujours vérifier l'implémentation IA plutôt que faire confiance aveuglément, même pour des tâches simples
- Tester sans cache est essentiel pour identifier les vrais problèmes de performance
- Les IA peuvent omettre des étapes évidentes (supprimer l'ancien code) tout en implémentant des détails complexes
- Demander des optimisations après implémentation révèle souvent des améliorations que l'IA n'a pas faites initialement
- L'approche itérative "implémenter puis optimiser" fonctionne mieux que tout spécifier d'avance
- Les tests automatiques IA (curl, rate limiting) sont appréciables mais les tests frontend HTML sont inutiles
- La sécurité doit être explicitement vérifiée - l'IA n'alerte pas sur l'exposition de données sensibles
- Copier-coller du contenu existant vers l'IA accélère le développement mais introduit du bruit
- Les IA ajoutent parfois des fonctionnalités non demandées mais utiles (email pré-rempli, ID référence)
- Le biais de satisfaction IA pousse à proposer toujours plus d'optimisations, même superflues
- Git commit nécessite validation manuelle pour éviter de versionner des données sensibles ou fichiers temporaires
- Les détails UX (symboles, animations) demandent souvent des corrections manuelles post-implémentation
- L'architecture "endpoint backend + frontend JavaScript" reste la bonne pratique pour sécuriser les clés API
- Le vibe coding oscille entre efficacité remarquable et erreurs basiques nécessitant vigilance constante