Continue la plateforme avec Zite (partie 3)
Alexis poursuit le développement de la plateforme du Cercle des Ops en implémentant la gestion complète des évaluations, le système de commentaires/réponses et l'optimisation de l'affichage des solutions avec filtrage par outils.
À propos de cette session
Alexis commence par faire l'état des lieux des fonctionnalités déjà développées : pages de login, tableau de bord, liste des challenges et page de soumission de solutions. Il s'attaque ensuite à l'amélioration de l'affichage des solutions en ajoutant des filtres par outils utilisés et des compteurs dynamiques. La mise en cache devient rapidement un enjeu identifié mais reporté.
Il développe ensuite une page détaillée pour chaque solution incluant les métadonnées, la vidéo embed générée automatiquement via une API, et la description. L'affichage des commentaires et réponses nécessite un travail sur la mise en page et la logique d'affichage conditionnel.
L'implémentation du formulaire d'évaluation en overlay se révèle problématique. Zite crée l'interface mais oublie le workflow back-end, obligeant Alexis à le demander explicitement. Des problèmes de quotas API Airtable apparaissent quand l'IA fait trop de requêtes simultanées.
La gestion des permissions devient complexe : empêcher l'auto-évaluation, détecter les évaluations déjà laissées, permettre les réponses seulement aux auteurs des solutions. Alexis doit contourner des bugs de logique en guidant précisément l'IA sur les champs de base de données à utiliser.
La session se termine par l'implémentation réussie du système de réponses aux commentaires et des indicateurs visuels "à évaluer/déjà évalué" dans la liste des solutions.
Points clés
- Performance critique : Les temps de chargement deviennent problématiques, Airtable atteint ses quotas d'API à cause de requêtes mal optimisées par l'IA
- Logique conditionnelle complexe : La gestion des permissions et états utilisateur (connecté/auteur/déjà évalué) pousse Zite dans ses retranchements
- Nécessité de guidage précis : Pour les requêtes complexes, il faut explicitement indiquer les noms de champs et la logique métier, l'IA ne l'infère pas
- Workflows back-end oubliés : L'IA crée souvent l'interface sans implémenter la logique de sauvegarde, nécessitant des demandes explicites
- Gestion d'état problématique : Les longues sessions causent des bugs d'interface et des pertes de contexte
- Limitation du caching : L'absence de mise en cache côté Zite/Airtable crée des goulots d'étranglement majeurs
- Debugging par essai-erreur : Les messages d'erreur ne sont pas toujours explicites, obligeant à tâtonner
- Séparation front/back opaque : Le code back-end généré par Zite n'est pas visible, créant une dépendance forte
- Nommage de champs critique : Les espaces dans les noms de champs Airtable posent des problèmes d'interprétation
- Requêtes en boucle dangereuses : L'IA peut créer des boucles de requêtes qui explosent les quotas API sans prévenir
- Vendor lock-in assumé : Alexis accepte la dépendance à Zite en connaissance de cause pour la rapidité de développement
- Échelle de complexité : Au-delà d'un certain niveau de logique métier, le vibe coding devient moins efficace que le développement traditionnel
- Notion de MVP fonctionnel : Malgré les limites, la plateforme atteint un niveau de fonctionnalité utilisable
- Comparaison no-code/vibe-coding : Le résultat visuel surpasse largement les interfaces Softr traditionnelles mais avec des compromis techniques