feat: add full stage-2 multilingual support for 8 locales
Translate all 24 stage-2 chapters (frontend, backend, AI capabilities, assignments) to ja-jp, ko-kr, zh-tw, es-es, fr-fr, de-de, ar-sa, vi-vn. Update VitePress config with sidebar labels, nav links, and sidebar entries for each locale. Images reference zh-cn originals via absolute paths. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
sanbuphy
@@ -0,0 +1,574 @@
|
||||
# Introduction à Dify et intégration de base de connaissances
|
||||
|
||||
# Rappel du cours précédent
|
||||
|
||||
Dans les cours précédents, nous avons étudié en groupes la programmation IA, l'ingénierie des prompts et les fondamentaux de la génération d'images par IA. Ces contenus nous ont permis de mieux comprendre les limites et les capacités des différents grands modèles de langage (LLM, Large Language Model) ou modèles génératifs.
|
||||
|
||||
Pour vous aider à réviser le cours précédent, voici quelques questions de réflexion :
|
||||
|
||||
1. Qu'est-ce que la programmation IA ? Comment utiliser des outils de programmation IA (comme [z.ai](http://z.ai)) pour créer une page web ?
|
||||
2. Qu'est-ce qu'un grand modèle de langage ? Qu'est-ce que l'ingénierie des prompts et l'ingénierie du contexte ? Comment rédiger un prompt complexe ?
|
||||
3. Pour les trois directions que sont le texte, l'AI Coding et la génération d'images, comment jugez-vous de la puissance des modèles dans chaque domaine ?
|
||||
4. Qu'est-ce qu'une API ? Comment utiliser [z.ai](http://z.ai) pour se connecter à une API tierce ?
|
||||
|
||||
Si l'une de ces questions vous semble encore floue, vous pouvez revoir les documents du cours précédent, ou poser directement vos questions dans le groupe de discussion WeChat.
|
||||
|
||||
Dans ce cours, nous passerons des simples outils de texte et d'images IA à des plateformes de construction de flux de travail plus proches des besoins réels des entreprises. Nous évoluerons des chatbots vers les agents IA et les flux de travail (Workflows) IA, puis via une API nous créerons une page de robot « intelligent » interactive.
|
||||
|
||||
Si vous rencontrez des étapes difficiles à comprendre, ne vous inquiétez pas. Nous vous recommandons de faire régulièrement des captures d'écran de la page en cours d'utilisation et de les envoyer à un grand modèle pour obtenir des explications. Les modèles actuels peuvent répondre à la plupart des questions courantes.
|
||||
|
||||
Si après avoir posé votre question le problème persiste, n'hésitez pas à expérimenter par vous-même. N'ayez pas peur de vous tromper -- chaque tentative est une occasion d'apprendre et de progresser. Avec la pratique, vous deviendrez de plus en plus à l'aise !
|
||||
|
||||
# Ce que vous allez apprendre dans ce cours
|
||||
|
||||
1. Pourquoi passer des chatbots aux agents IA et à l'orchestration de Workflows.
|
||||
2. Qu'est-ce qu'un agent IA et une plateforme de développement de workflows, comment standardiser et orchestrer les capacités de l'IA.
|
||||
3. Qu'est-ce que Dify, comment utiliser cette plateforme open source orientée applications LLM pour construire rapidement des applications, notamment des chatbots à base de connaissances.
|
||||
4. Les méthodes d'implémentation et la valeur de RAG, pourquoi la génération augmentée par recherche est-elle nécessaire.
|
||||
5. Comment apprendre de 0 à 1 à utiliser Dify et l'IDE IA Trae (`Connaissances supplémentaires 4 - Qu'est-ce que l'IDE IA et Trae`), notamment construire des agents et des workflows, et créer une application frontend de chatbot via l'API Dify.
|
||||
|
||||
- Les principes de base de Dify, les méthodes de création d'agents et de workflows, et les méthodes d'appel API.
|
||||
- Comment utiliser un IDE IA pour la programmation.
|
||||
- Une application frontend de chatbot interactive.
|
||||
|
||||
# 1. De la conversation à l'agent
|
||||
|
||||
Au stade précédent, nous avons appris à utiliser des prompts pour faire jouer des rôles aux grands modèles, générer du texte ou écrire du code simple. Mais si l'on y réfléchit attentivement, on constate un problème : un chatbot en soi ne peut pas agir.
|
||||
|
||||
Il peut expliquer comment vérifier une commande, mais ne peut pas réellement aller chercher les chiffres dans la base de données ; il peut décrire ce que devrait contenir un rapport hebdomadaire, mais ne peut pas automatiquement consolider les données du projet et envoyer un email. Cette limite du « dire sans faire » rend l'IA purement conversationnelle difficile à intégrer véritablement dans les processus métier.
|
||||
|
||||
Pour faire évoluer l'IA d'un simple partenaire de conversation vers un employé numérique, nous devons lui conférer trois capacités fondamentales :
|
||||
|
||||
1. Des connaissances dédiées -- lui permettre d'assimiler et comprendre vos documents produit, les profils clients, les politiques internes ;
|
||||
2. L'appel d'outils (ou plugins) -- lui permettre d'opérer sur des bases de données, d'appeler des API ;
|
||||
3. L'exécution structurée -- lui faire accomplir les tâches selon une logique prédéfinie, étape par étape, plutôt qu'en improvisant librement.
|
||||
|
||||
C'est l'ébauche d'un agent IA (AI Agent) : une unité automatisée dotée d'un objectif, de connaissances, d'outils et d'un chemin d'exécution.
|
||||
|
||||
|
||||
|
||||
> Note : ce que l'industrie appelle actuellement des « agents » simples désigne généralement des applications enrichies basées sur la combinaison LLM + outils + base de connaissances, et non des agents capables de planifier de manière autonome. Bien que ces agents simples ne possèdent pas de véritables capacités de raisonnement et de planification à long terme, ils suffisent déjà à couvrir de nombreux scénarios d'automatisation en entreprise. Nous présenterons en détail dans les chapitres suivants les véritables agents capables de planification et d'action autonomes.
|
||||
|
||||
## 1.1 Le plus simple des agents : le chatbot à base de connaissances
|
||||
|
||||
Après avoir identifié les multiples capacités fondamentales d'un agent, une question se pose : peut-on, en implémentant uniquement la plus simple de ces fonctionnalités, construire un agent de base véritablement utilisable ? La réponse est oui.
|
||||
|
||||
En fait, dans de nombreux scénarios métier réels, le besoin central des utilisateurs n'est pas que l'IA exécute automatiquement des opérations complexes (comme appeler des API ou coordonner des tâches entre systèmes), mais plutôt qu'elle fournisse des réponses précises et fiables basées sur les documents propres à l'entreprise. Cela correspond exactement à la première des trois capacités fondamentales : le service de connaissances dédiées. Nous pouvons donc introduire la forme la plus simple et la plus répandue d'agent : le chatbot à base de connaissances.
|
||||
|
||||
Bien qu'il ne possède pas encore de capacités d'appel d'outils ou de planification autonome, sa avancée clé est la suivante : les réponses du grand modèle ne sont plus générées à partir de rien, mais s'appuient sur des sources vérifiables. Comment y parvenir ? La solution repose sur la génération augmentée par recherche (Retrieval-Augmented Generation, RAG).
|
||||
|
||||
L'idée fondamentale de RAG est la suivante : lorsque l'utilisateur pose une question, le système recherche d'abord dans la base de connaissances de l'entreprise les extraits de texte les plus pertinents sémantiquement (par exemple un passage du manuel produit, un article du règlement RH), puis injecte ces extraits comme contexte dans l'entrée du grand modèle, pour guider celui-ci à générer une réponse fondée sur des données réelles.
|
||||
|
||||
|
||||
|
||||
Source de l'image : [https://www.datacamp.com/blog/what-is-retrieval-augmented-generation-rag](https://www.datacamp.com/blog/what-is-retrieval-augmented-generation-rag)
|
||||
|
||||
Ainsi, les réponses du modèle ne dépendent plus de ses connaissances générales issues des données d'entraînement, mais s'ancrent sur les informations authentiques fournies par l'entreprise. L'objectif de RAG est précisément d'améliorer significativement la véracité, la précision et la cohérence des réponses grâce à cette injection dynamique de connaissances externes -- pouvant même adapter le ton (par exemple répondre dans le style d'un service client ou d'une documentation technique).
|
||||
|
||||
En pratique, cette technologie est particulièrement importante car les grands modèles produisent souvent des « hallucinations ». Par exemple, si vous demandez des données spécifiques en vous faisant passer pour un directeur financier ou un consultant, le modèle risque d'inventer des dates et des événements. Avec RAG, la contrôlabilité et la fiabilité des réponses sont considérablement améliorées.
|
||||
|
||||
|
||||
|
||||
Source de l'image : [https://www.databricks.com/glossary/retrieval-augmented-generation-rag](https://www.databricks.com/glossary/retrieval-augmented-generation-rag)
|
||||
|
||||
Dans la partie pratique de ce cours, nous utiliserons la plateforme de workflows IA populaire Dify pour construire un chatbot à base de connaissances. Vous pourrez facilement constituer une base de connaissances à partir de divers documents dédiés : manuels produits, politiques internes, documents de projet, articles de recherche, notes personnelles.
|
||||
|
||||
Une fois la construction terminée, vous pourrez tester ses capacités avec différentes questions, par exemple :
|
||||
|
||||
- « Quelles sont les principales nouveautés de la dernière version de notre produit A ? »
|
||||
- « Selon le manuel du personnel, comment fonctionne le système de congés cette année ? »
|
||||
- « Dans le projet XX, comment avons-nous résolu le défi technique "XXX" ? »
|
||||
- « Quelle est la méthode de recherche centrale mentionnée dans cet article ? »
|
||||
|
||||
Vous découvrirez par vous-même comment RAG transforme des documents dispersés en une base de connaissances intelligente et précise.
|
||||
|
||||
## 1.2 De l'agent conversationnel au workflow
|
||||
|
||||
Cependant, même un « agent enrichi » disposant d'une base de connaissances et de capacités d'appel de plugins se révèle insuffisant face à des processus métier plus complexes.
|
||||
|
||||
Prenons une demande utilisateur : « Quelles sont les dernières mises à jour fonctionnelles de notre produit SaaS récemment lancé ? Peux-tu me préparer un briefing pour les clients ? »
|
||||
|
||||
Cette demande semble simple, mais elle nécessite plusieurs étapes coordonnées : d'abord extraire les enregistrements de lancement du mois écoulé depuis la documentation interne ou la base de connaissances Notion ; puis filtrer les fonctionnalités clés orientées client ; ensuite appeler un grand modèle pour convertir les descriptions techniques en langage client-friendly ; enfin pousser le contenu généré vers l'équipe marketing par email, ou le sauvegarder dans un template Google Docs.
|
||||
|
||||
Si l'on s'en remet uniquement au raisonnement libre d'un seul grand modèle, non seulement il est peu probable de tout réaliser en une seule conversation, mais le risque est grand d'omettre des informations clés, de confondre le jargon interne et le langage client, ou de produire un résultat non structuré. Plus important encore, l'entreprise a besoin de parcours d'exécution standardisés, auditables, réutilisables et surveillables, et non d'une improvisation dépendant du modèle à chaque fois. La reproductibilité et la surveillance sont cruciales pour les entreprises -- des résultats inattendus peuvent entraîner des pertes graves.
|
||||
|
||||
C'est ce qui nous mène au paradigme d'application IA de niveau supérieur : le workflow IA (AI Workflow).
|
||||
|
||||
|
||||
|
||||
Un workflow désigne la décomposition d'une tâche complexe en plusieurs sous-étapes ordonnées, configurables et exécutables automatiquement, dont les relations logiques (conditions, boucles, parallélisme) sont orchestrées de manière visuelle ou par code. Standardiser les capacités IA (c'est-à-dire les transformer en procédures opérationnelles standardisées) signifie cristalliser l'expérience de l'utilisation de l'IA pour une tâche donnée en un template réutilisable.
|
||||
|
||||
Cette approche offre de multiples avantages : les non-techniciens (comme les chefs de produit ou les responsables marketing) peuvent assembler rapidement des applications IA par glisser-déposer de composants ; les développeurs peuvent encapsuler la recherche RAG, les appels LLM, les outils API en nœuds standardisés, réutilisables dans différents scénarios métier ; l'ensemble du processus peut être tracé, débogué et optimisé en continu, répondant aux exigences de stabilité et de conformité des entreprises.
|
||||
|
||||
L'utilisation des workflows IA touche un public très large. Les chefs de produit peuvent concevoir des parcours utilisateur complets sans coder ; les équipes marketing peuvent rapidement construire des chatbots de service client, des générateurs de contenu ou des systèmes de notification ; les développeurs et ingénieurs peuvent modulariser les capacités clés pour les appels frontend ; les entrepreneurs ou développeurs indépendants peuvent valider un MVP de produit IA à moindre coût, en mettant en ligne en quelques jours un prototype complet incluant interrogation de données, génération de contenu et exécution d'actions.
|
||||
|
||||
En résumé, si les agents font passer l'IA du stade de « savoir discuter » à « savoir agir », les workflows la font passer de « réussir parfois une tâche » à « accomplir de manière stable, fiable et à grande échelle une catégorie de tâches ». Dans la pratique qui suit, nous utiliserons la plateforme Dify pour construire de nos propres mains un workflow IA complet.
|
||||
|
||||
## 1.3 Plateformes d'agents et de workflows courantes
|
||||
|
||||
Avec le développement rapide de l'IA générative, un ensemble de plateformes low-code voire no-code d'agents et de workflows ont émergé pour aider les développeurs et les équipes métier à construire rapidement des agents et des processus automatisés, sans se perdre dans la complexité de la programmation.
|
||||
|
||||
La notion clé de plateforme low-code désigne des outils de développement réduisant considérablement le codage manuel grâce à des composants glisser-déposer visuels, des templates de logique métier prédéfinis et une configuration graphique des règles. Leur cœur est de remplacer l'écriture de code par une configuration visuelle et un assemblage de nœuds par glisser-déposer, libérant les développeurs des tâches répétitives tout en permettant aux non-techniciens maîtrisant la logique métier de participer à la construction d'applications.
|
||||
|
||||
La valeur essentielle de ces plateformes est de réduire considérablement le seuil d'entrée pour le développement d'applications IA. Ce qui nécessitait auparavant une collaboration d'équipe pendant des semaines -- de l'analyse des besoins au développement, tests et déploiement -- peut désormais être accompli en quelques heures grâce aux outils visuels de ces plateformes.
|
||||
|
||||
Les principales plateformes de workflows IA low-code actuellement sur le marché :
|
||||
|
||||
| Plateforme | Caractéristiques | Scénarios d'utilisation |
|
||||
| --- | --- | --- |
|
||||
| Dify | Open source, RAG, orchestration LLM, API, adapté au chinois | Base de connaissances entreprise, agents personnalisés, services API |
|
||||
| Coze (ByteDance) | Disponible en Chine, intégration Douyin/Lark, plugins riches | Bots sociaux, intégration mini-programmes |
|
||||
| n8n | Automatisation générale, nœuds IA, orchestration API | Synchronisation inter-systèmes, automatisation IA + SaaS |
|
||||
| Baidu Qianfan / Alibaba Bailian / Tencent HunYuan | Solutions cloud natives des grands groupes | Déploiement entreprise, haute conformité |
|
||||
|
||||
Dify, Coze et n8n se distinguent par trois avantages clés :
|
||||
|
||||
1. Facilité d'utilisation extrême. Interface glisser-déposer visuelle, prise en main rapide sans comprendre la technologie sous-jacente.
|
||||
2. Grande flexibilité. Composants personnalisés et API extensibles, adaptés aux scénarios légers (démonstrations, MVP) comme aux besoins d'itération agile des PME.
|
||||
3. Écosystème mature. Documentation officielle détaillée, réponse rapide, communauté active avec de nombreux templates partagés.
|
||||
|
||||
Ces trois plateformes permettent toutes d'exposer les agents construits sous forme d'API standardisée, intégrables dans les applications web frontend, les systèmes ERP internes ou les apps mobiles.
|
||||
|
||||
### 1.3.1 Dify : plateforme LLMOps d'entreprise
|
||||
|
||||
Dify se positionne comme une plateforme de développement et d'exploitation d'applications LLM, dédiée à la gestion du cycle de vie complet, de la conception au déploiement et à l'optimisation.
|
||||
|
||||
|
||||
|
||||
En termes de fonctionnalités, Dify couvre l'orchestration visuelle de workflows, la construction d'agents, la gestion de bases de connaissances et le support multi-modèles. La plateforme permet de concevoir des flux de tâches complexes par glisser-déposer de nœuds et supporte la création d'agents basés sur les intentions. Sa fonctionnalité de base de connaissances est particulièrement aboutie, capable de traiter de multiples formats de documents avec une recherche vectorielle efficace.
|
||||
|
||||
|
||||
|
||||
### 1.3.2 Coze (ByteDance)
|
||||
|
||||
Coze est la plateforme de développement d'agents IA de ByteDance, centrée sur la facilité d'utilisation extrême.
|
||||
|
||||
|
||||
|
||||
Sa particularité est de simplifier la construction de bots en un assemblage de type « briques LEGO ». Les bots créés peuvent être publiés en un clic sur Doubao, Lark, WeChat et d'autres plateformes.
|
||||
|
||||
|
||||
|
||||
### 1.3.2 n8n : moteur d'automatisation de workflows programmable
|
||||
|
||||
n8n est une plateforme d'automatisation de workflows programmable et polyvalente, dont le positionnement central est de connecter applications, bases de données et API pour automatiser les flux de données et l'exécution de tâches.
|
||||
|
||||
|
||||
|
||||
Sa caractéristique technique clé est le « code source visible » et l'« auto-hébergement », permettant un déploiement privé pour un contrôle total des données et de l'environnement. Son principal atout réside dans son écosystème communautaire extrêmement riche.
|
||||
|
||||
# 2. Dify en profondeur
|
||||
|
||||
## 2.1 Qu'est-ce que Dify
|
||||
|
||||
Dify est une plateforme open source pour le développement d'applications LLM. Elle offre une interface intuitive combinant workflows d'agents, pipelines RAG, capacités d'outils, gestion de modèles et observabilité, pour vous aider à passer rapidement du prototype à la production.
|
||||
|
||||
|
||||
|
||||
Construire un workflow dans Dify, c'est comme assembler des briques LEGO ou un puzzle. Vous connectez des « nœuds LLM » (compréhension et génération), des « nœuds outils » (exécution d'actions spécifiques : interrogation de base de données, envoi d'email, traduction) et des « nœuds de données » (lecture, stockage d'informations) entre eux. Ils fonctionnent automatiquement selon la logique prédéfinie, sans intervention manuelle répétée.
|
||||
|
||||
Par exemple, si vous dirigez un magasin e-commerce Amazon ou Douyin et souhaitez construire un service client IA, vous pouvez concevoir un workflow comme suit :
|
||||
|
||||
1. Nœud déclencheur : reçoit la question de l'utilisateur.
|
||||
2. Nœud de classification : utilise un modèle pour classer la question (service après-vente, mode d'emploi, etc.).
|
||||
3. Nœud de recherche de connaissances : accède à la base de connaissances correspondante.
|
||||
4. Nœud LLM : génère une réponse conviviale à partir de la question et des connaissances récupérées.
|
||||
5. Nœud de condition : vérifie si la réponse contient les informations attendues.
|
||||
6. Nœud de sortie : renvoie la réponse finale à l'utilisateur.
|
||||
|
||||
|
||||
|
||||
### 2.1.1 Déployer votre propre Dify (optionnel)
|
||||
|
||||
Consultez le tutoriel : [Comment déployer une application Web](/fr-fr/stage-2/backend/zeabur-deployment/)
|
||||
|
||||
|
||||
|
||||
## 2.2 Créer votre première application Chatbot Dify
|
||||
|
||||
Accédez à [https://cloud.dify.ai/apps](https://cloud.dify.ai/apps), inscrivez-vous et connectez-vous, puis sélectionnez Studio.
|
||||
|
||||
|
||||
|
||||
Cliquez sur `Create from Blank` dans la section `CREATE APP`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Sélectionnez Chatbot comme type d'application, saisissez un nom et une description, puis créez.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
La zone « INSTRUCTIONS » correspond aux instructions intégrées (prompt système par défaut).
|
||||
|
||||
La zone « Knowledge » en dessous est la zone de base de connaissances.
|
||||
|
||||
Le panneau de droite est la fenêtre de débogage pour tester les réponses en temps réel.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 2.3 Prendre en charge les fournisseurs de modèles personnalisés
|
||||
|
||||
Dify prend en charge la configuration de trois types de modèles : LLM, Embedding et Rerank.
|
||||
|
||||
Installez les plugins `OpenAI-API-compatible` et `SiliconFlow` pour accéder à la plupart des modèles.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 2.4 Créer votre première base de connaissances Dify
|
||||
|
||||
Cliquez sur `Knowledge` dans le menu supérieur pour accéder à la page de création de base de connaissances.
|
||||
|
||||
|
||||
|
||||
Cliquez sur `Create Knowledge`.
|
||||
|
||||
|
||||
|
||||
Chargez vos fichiers (PDF, TXT, etc.) pour construire la base de connaissances.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 2.5 Autres opérations courantes dans Dify
|
||||
|
||||
### 2.5.1 Importer et exporter des workflows
|
||||
|
||||
Dify prend en charge l'import/export de workflows au format DSL (JSON).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 2.5.2 Explorer plus de projets Dify
|
||||
|
||||
Cliquez sur Explora pour voir les workflows construits par d'autres.
|
||||
|
||||
|
||||
|
||||
## 2.6 Créer votre première application Workflow Dify
|
||||
|
||||
Sélectionnez Chatflow ou Workflow selon que votre besoin est une conversation continue ou un processus automatisé.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- **Chatflow** : conçu pour les conversations, avec mémoire et contexte.
|
||||
- **Workflow** : conçu pour l'automatisation, traitement ponctuel entrée -> sortie.
|
||||
|
||||
|
||||
|
||||
### 2.6.1 Nœuds courants
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Nœuds LLM et de raisonnement :**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- LLM : unité de calcul principale appelant le grand modèle.
|
||||
- Knowledge Retrieval : recherche dans les bases de connaissances.
|
||||
- Answer : sortie des résultats.
|
||||
- Agent : prise de décision avancée avec outils.
|
||||
- Question Classifier : classification des questions par type.
|
||||
|
||||
**Nœuds de logique et contrôle de flux :**
|
||||
|
||||
|
||||
|
||||
- Condition (IF/ELSE) : branchement logique.
|
||||
- Iteration : traitement parallèle par lots sans état.
|
||||
- Loop : itération récursive avec état.
|
||||
|
||||
**Nœuds de manipulation de données et intégration :**
|
||||
|
||||
|
||||
|
||||
- Code : logique personnalisée en code.
|
||||
- Template : génération de contenu à partir de templates.
|
||||
- Variable Aggregator : consolidation de variables.
|
||||
- Doc Extractor : extraction depuis documents.
|
||||
- HTTP Request : appels vers des systèmes externes.
|
||||
- List Operator : opérations sur listes/tableaux.
|
||||
|
||||
### 2.6.2 Outils courants
|
||||
|
||||
|
||||
|
||||
Les outils dans Dify peuvent être placés directement sur le canevas comme des nœuds.
|
||||
|
||||
- **Recherche web** : Tavily Search pour une recherche optimisée pour l'IA.
|
||||
- **Traitement de données** : JSON Process pour les opérations avancées sur JSON.
|
||||
- **Formatage** : Markdown Exporter pour l'export dans des formats spécifiés.
|
||||
|
||||
### 2.6.3 Créer un workflow simple de classification d'intention
|
||||
|
||||
Pour un scénario de restaurant, nous créons un workflow capable de classer les intentions des utilisateurs en quatre catégories : commande (buy_food), réclamation (complain), conversation (chitchat) et autre (other).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Test du workflow
|
||||
|
||||
|
||||
|
||||
## 2.7 Exécuter un workflow template
|
||||
|
||||
Importez le workflow DeepResearch officiel et corrigez les erreurs au fur et à mesure.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 2.8 Utiliser Dify comme fournisseur d'API
|
||||
|
||||
Nous allons maintenant appeler l'agent à base de connaissances créé précédemment via l'API Dify.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 2.9 Créer une application frontend de conversation via l'API Dify
|
||||
|
||||
Publiez d'abord l'agent, puis accédez à la documentation API.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Utilisez Trae Builder avec votre clé API, la requête et la réponse exemples pour générer le code frontend.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# 3. Références de workflows métier supplémentaires
|
||||
|
||||
Vous pouvez rechercher sur Internet avec des mots-clés comme « Dify workflow examples » ou trouver des dépôts GitHub partageant des workflows Dify.
|
||||
|
||||
Voici quelques idées de workflows générées par un grand modèle :
|
||||
|
||||
## 3.1 Workflows pour plateformes sociales
|
||||
|
||||
1. Distribution multi-plateforme en un clic (complexe)
|
||||
2. Générateur de sujets tendance et brouillons (moyen)
|
||||
3. Assistant de classification et réponse aux commentaires (complexe)
|
||||
4. Générateur de scripts et storyboards vidéo (complexe)
|
||||
5. Résumé en temps réel des interactions en live (moyen)
|
||||
|
||||
## 3.2 Workflows professionnels
|
||||
|
||||
1. Compte-rendu de réunion intelligent et assignation automatique de tâches (complexe)
|
||||
2. Filtrage et évaluation automatisée de CV (moyen)
|
||||
3. Traduction et réponse multilingue par email (simple)
|
||||
4. Consolidation automatique de rapports hebdomadaires/mensuels (complexe)
|
||||
5. Révision intelligente de contrats/documents (moyen)
|
||||
|
||||
## 3.3 Workflows pour l'apprentissage et la vie quotidienne
|
||||
|
||||
1. Analyseur approfondi d'articles académiques avec génération de notes (complexe)
|
||||
2. Planificateur de voyage personnalisé (moyen)
|
||||
3. Partenaire de pratique linguistique interactif (simple)
|
||||
4. Système de Q&R sur base de connaissances personnelle (complexe)
|
||||
5. Conseiller fitness/nutrition avec suivi (moyen)
|
||||
|
||||
# 6. Limites des plateformes de workflows
|
||||
|
||||
Les plateformes de workflows (ou plateformes low-code) ne sont pas des solutions universelles. Bien qu'elles soient conviviales pour les profils métier et réduisent le seuil de codage, le « low-code » implique aussi son propre coût d'apprentissage : l'utilisateur doit comprendre les concepts, règles et logique opérationnelle de la plateforme.
|
||||
|
||||
Vous pourriez légitimement vous demander : beaucoup de workflows simples ne sont que des appels de fonctions de grand modèle enchaînés, l'output de l'un devenant l'input du suivant, ce qui pourrait être résolu en quelques lignes de code. Pourquoi nécessiter une infrastructure de workflow aussi complexe ?
|
||||
|
||||
Vous avez raison. Avec le développement rapide du vibe coding et les capacités de génération de code par l'IA, lire voire générer du code directement peut parfois être plus efficace. Idéalement, nous pourrions piloter la logique applicative en langage naturel -- ce serait une véritable plateforme logicielle moderne. Mais les plateformes de workflow actuelles ne l'ont pas encore atteint, créant un « intermédiaire » naturel entre l'intention de l'utilisateur et la réalisation finale.
|
||||
|
||||
Néanmoins, la maîtrise de ces plateformes devient une compétence de base, analogue aux outils bureautiques Microsoft, très répandue et utile en entreprise.
|
||||
|
||||
# 📚 Exercice final
|
||||
|
||||
## Maîtriser les opérations de base de Dify
|
||||
|
||||
1. Créez un workflow de classification d'intention dans un scénario entièrement différent.
|
||||
2. Défi de workflow « Login » : trouvez le bon mot de passe, modifiez-le, ajoutez une deuxième tentative.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. Défi de workflow « Love loop » : corrigez le workflow pour obtenir la sortie attendue.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Implémenter l'appel API Dify
|
||||
|
||||
1. Déployez Dify et créez une base de connaissances simple.
|
||||
2. Utilisez Trae IDE pour construire un frontend de conversation interagissant via l'API Dify.
|
||||
3. Testez les conversations multi-tours.
|
||||
|
||||
## Essayer un workflow tiers ou construire le vôtre
|
||||
|
||||
Trouvez un workflow Dify sur Github, WeChat, Reddit ou Twitter, importez-le et exécutez-le avec succès.
|
||||
|
||||
# [Bug] Solution au problème d'erreur de requête HTTP
|
||||
|
||||
Si vous rencontrez le problème illustré ci-dessous, consultez cette section ; sinon vous pouvez l'ignorer.
|
||||
|
||||
|
||||
|
||||
Ce problème survient lorsque Dify est déployé sur un serveur ne supportant que HTTP (sans HTTPS). Le HTTPS (HyperText Transfer Protocol Secure) est une version sécurisée du HTTP avec chiffrement SSL/TLS.
|
||||
|
||||
Solutions possibles :
|
||||
- Utiliser un proxy inverse avec certificat (nginx)
|
||||
- Lier un domaine et obtenir un certificat
|
||||
|
||||
Nous utiliserons Zeabur comme passerelle réseau pour résoudre ce problème :
|
||||
|
||||
- Adresse d'origine : `http://{DIFY_API_URL}/v1/chat-messages`
|
||||
- Nouvelle adresse : `https://{DIFY_NEW_API_URL}.zeabur.app/v1/chat-messages`
|
||||
|
||||
Vous pouvez déployer un service proxy sur Zeabur en sélectionnant Python et en utilisant le code suivant :
|
||||
|
||||
```python
|
||||
from flask import Flask, request, Response
|
||||
import requests
|
||||
|
||||
app = Flask(__name__)
|
||||
|
||||
TARGET_BASE_URL = "{DIFY_API_URL}"
|
||||
LISTEN_PORT = 8080
|
||||
|
||||
@app.route('/', defaults={'path': ''}, methods=['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'OPTIONS', 'HEAD'])
|
||||
@app.route('/<path:path>', methods=['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'OPTIONS', 'HEAD'])
|
||||
def proxy_request(path):
|
||||
target_url = f"{TARGET_BASE_URL}/{path}"
|
||||
if request.query_string:
|
||||
target_url += f"?{request.query_string.decode('utf-8')}"
|
||||
|
||||
headers = {key: value for key, value in request.headers if key.lower() not in ['host', 'connection', 'content-length', 'accept-encoding']}
|
||||
|
||||
try:
|
||||
resp = requests.request(
|
||||
method=request.method,
|
||||
url=target_url,
|
||||
headers=headers,
|
||||
data=request.get_data(),
|
||||
cookies=request.cookies,
|
||||
allow_redirects=False,
|
||||
timeout=30
|
||||
)
|
||||
|
||||
excluded_headers = ['content-encoding', 'content-length', 'transfer-encoding', 'connection']
|
||||
response_headers = [(name, value) for name, value in resp.raw.headers.items() if name.lower() not in excluded_headers]
|
||||
|
||||
return Response(resp.content, resp.status_code, response_headers)
|
||||
|
||||
except requests.exceptions.RequestException as e:
|
||||
print(f"Error forwarding request to {target_url}: {e}")
|
||||
return Response(f"Proxy Error: Could not reach target server or invalid response: {e}", status=502)
|
||||
except Exception as e:
|
||||
print(f"An unexpected error occurred: {e}")
|
||||
return Response(f"Internal Proxy Error: {e}", status=500)
|
||||
|
||||
if __name__ == '__main__':
|
||||
app.run(host='0.0.0.0', port=LISTEN_PORT, debug=True)
|
||||
```
|
||||
@@ -0,0 +1,346 @@
|
||||
# Projet 1 : Première application full-stack SaaS — Site de génération de copywriting
|
||||
|
||||
## Présentation
|
||||
|
||||
Ce projet pratique vous demande de réaliser, à partir d'un véritable PRD (Document d'Exigences Produit), un produit SaaS de copywriting marketing IA destiné aux développeurs indépendants et aux équipes de contenu. Vous utiliserez Supabase comme service backend et Stripe comme système de paiement, en parcourant l'ensemble du processus, de l'analyse des besoins au déploiement en ligne.
|
||||
|
||||
Il s'agit du projet pratique synthétique de l'Étape 2. Dans les chapitres précédents, vous avez appris séparément la création de pages frontend, le développement d'interfaces backend, les opérations de base de données et l'intégration de paiements — ce projet vous demande de tout assembler pour livrer un prototype de produit fonctionnel.
|
||||
|
||||
## Prérequis
|
||||
|
||||
Avant de commencer ce projet, vous devriez maîtriser les sujets suivants :
|
||||
|
||||
- Conception de pages frontend et utilisation de bibliothèques de composants ([Conception UI](../../frontend/ui-design/), [Bibliothèque de composants moderne](../../frontend/modern-component-library/))
|
||||
- Conception et développement d'interfaces backend ([Conception et développement d'interfaces backend](../../backend/ai-interface-code/))
|
||||
- Bases de données et Supabase ([De la base de données à Supabase](../../backend/database-supabase/))
|
||||
- Intégration de paiements ([Système de paiement Stripe](../../backend/stripe-payment/))
|
||||
- Flux de travail Git et déploiement ([Git et GitHub](../../backend/git-workflow/), [Déployer une application web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Objectifs d'apprentissage
|
||||
|
||||
Après avoir terminé ce projet, vous serez capable de :
|
||||
|
||||
1. Lire et comprendre un véritable PRD et en extraire une liste de tâches de développement
|
||||
2. Utiliser l'IA pour générer étape par étape les pages frontend et les interfaces backend
|
||||
3. Utiliser Supabase pour l'authentification utilisateur et les opérations de base de données
|
||||
4. Intégrer Stripe pour la fonctionnalité d'abonnement payant
|
||||
5. Construire une console d'administration et effectuer des tests de bout en bout
|
||||
|
||||
## Présentation du projet
|
||||
|
||||
Le produit que vous allez construire est un SaaS de copywriting marketing IA, comprenant trois sous-systèmes :
|
||||
|
||||
| Sous-système | Responsabilité |
|
||||
|--------|------|
|
||||
| **Site vitrine** | Présentation du produit, tarification, FAQ, conversion à l'inscription |
|
||||
| **Espace utilisateur** | Saisie des informations produit, génération de copywriting, historique, mise à niveau du forfait |
|
||||
| **Console d'administration** | Gestion des utilisateurs, enregistrements de génération, données de paiement, vue d'ensemble des opérations |
|
||||
|
||||
Le backend utilise Supabase pour la base de données et l'authentification, Stripe pour les paiements, et un modèle IA pour générer le copywriting marketing.
|
||||
|
||||
::: tip Accès au PRD
|
||||
Le document d'exigences de ce projet se trouve sur GitHub : [Voir le PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/copywriting-platform-supabase/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Analyse des besoins', description: 'Lire le PRD, clarifier les pages, fonctionnalités, authentification et périmètre de paiement' },
|
||||
{ title: 'Structure du projet', description: 'Générer trois squelettes frontend avec l\'IA (www / app / admin)' },
|
||||
{ title: 'Intégration backend', description: 'Authentification Supabase, interface de génération, paiement Stripe' },
|
||||
{ title: 'Tests et déploiement', description: 'Tests de bout en bout, déploiement et préparation de la démonstration' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Partie 1 : Analyse des besoins
|
||||
|
||||
### 1.1 Lire le PRD
|
||||
|
||||
Ouvrez le document PRD et répondez aux questions suivantes :
|
||||
|
||||
- Combien d'entrées le système possède-t-il ? Quelles pages couvre chacune ?
|
||||
- Quelle est la fonction principale de chaque page ?
|
||||
- Quels modules et tables de données le backend comprend-il ?
|
||||
- Comment la tarification, le processus de paiement et le quota gratuit sont-ils conçus ?
|
||||
- Quel est le périmètre MVP ? Que fait-on et que ne fait-on pas dans la première version ?
|
||||
|
||||
::: warning
|
||||
Si vous n'avez pas de réponses claires aux questions ci-dessus, ne commencez pas à coder. Une mauvaise compréhension des besoins est la cause la plus fréquente de rework.
|
||||
:::
|
||||
|
||||
### 1.2 Confirmer l'architecture du système
|
||||
|
||||
D'après le PRD, dégagez l'architecture globale du système :
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["Site vitrine"]
|
||||
prd --> app["Espace utilisateur"]
|
||||
prd --> admin["Console d'administration"]
|
||||
app --> auth["Authentification"]
|
||||
app --> gen["Tâches de génération de copywriting"]
|
||||
gen --> db["Base de données"]
|
||||
billing["Paiement et forfaits"] --> db
|
||||
admin --> analytics["Tableau de bord utilisateurs / génération / paiements"]
|
||||
```
|
||||
|
||||
## Partie 2 : Structure du projet
|
||||
|
||||
### 2.1 Générer les pages frontend
|
||||
|
||||
Utilisez l'IA pour générer d'abord la structure de base de toutes les pages avec des données fictives.
|
||||
|
||||
Prompt de référence :
|
||||
|
||||
```text
|
||||
Générez un squelette frontend pour un SaaS de copywriting marketing IA, basé sur le PRD actuel.
|
||||
|
||||
Exigences :
|
||||
1. Trois entrées séparées : www, app, admin
|
||||
2. Le site vitrine comprend : page d'accueil, tarification, FAQ
|
||||
3. L'app comprend : connexion, inscription, espace de génération, historique, page des forfaits
|
||||
4. L'admin comprend : page d'accueil backend, gestion des utilisateurs, enregistrements de génération, commandes de paiement
|
||||
5. Ne générez que la structure des pages et des données fictives, sans interfaces réelles
|
||||
6. Le style doit ressembler à un SaaS moderne, pas à une démo de classe
|
||||
```
|
||||
|
||||
### 2.2 Améliorer les pages principales
|
||||
|
||||
Une fois la structure en place, concentrez-vous sur l'amélioration de la page de l'espace de génération (Dashboard) :
|
||||
|
||||
```text
|
||||
Continuez à améliorer la page /dashboard.
|
||||
|
||||
C'est un espace de génération de copywriting marketing IA.
|
||||
|
||||
Champs du formulaire à gauche :
|
||||
- Nom du produit
|
||||
- Description en une phrase
|
||||
- Utilisateurs cibles
|
||||
- 3 arguments de vente
|
||||
- Canaux de distribution (site web, WeChat Moments, Xiaohongshu, Douyin, email)
|
||||
|
||||
Zone de résultats à droite :
|
||||
- Titre principal
|
||||
- Sous-titre
|
||||
- CTA
|
||||
- 3 versions de copywriting court
|
||||
- Copywriting long
|
||||
|
||||
Utilisez d'abord des données mock pour valider l'interaction.
|
||||
|
||||
Exigences :
|
||||
- État de chargement après clic sur « Générer le copywriting »
|
||||
- Concevoir un état vide pour la zone de résultats
|
||||
- Mise en page responsive, adaptée aux écrans larges et étroits
|
||||
```
|
||||
|
||||
### 2.3 Vérifier la structure des pages
|
||||
|
||||
Vérifiez chaque élément :
|
||||
|
||||
- [ ] Les routes des trois entrées sont-elles indépendantes
|
||||
- [ ] Le nombre de pages correspond-il au PRD
|
||||
- [ ] La mise en page du formulaire et de la zone de résultats du Dashboard est-elle raisonnable
|
||||
- [ ] Les données fictives présentent-elles les états UI de base
|
||||
|
||||
### Bloqué ?
|
||||
|
||||
Si vous êtes bloqué lors de la construction du frontend, vous pouvez consulter ces chapitres :
|
||||
|
||||
- [Conception UI](../../frontend/ui-design/)
|
||||
- [Concevoir des pages et des boutons en référence aux guidelines de conception UI](../../frontend/multi-product-ui/)
|
||||
- [Rendre l'interface attrayante avec les LLM et les Skills](../../frontend/llm-skills-beautiful/)
|
||||
- [Du prototype de conception au code de projet](../../frontend/design-to-code/)
|
||||
- [Mettre à jour votre interface avec une bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
|
||||
## Partie 3 : Intégration backend
|
||||
|
||||
### 3.1 Intégrer la connexion Supabase
|
||||
|
||||
```text
|
||||
Considérez que je suis débutant et guidez-moi étape par étape pour intégrer la connexion Supabase.
|
||||
|
||||
J'ai besoin que vous m'aidiez à :
|
||||
1. Intégrer Supabase dans le projet
|
||||
2. Implémenter les fonctions d'inscription, de connexion et de déconnexion
|
||||
3. Rediriger vers /dashboard après connexion réussie
|
||||
4. Rediriger automatiquement vers /login les utilisateurs non connectés accédant à /dashboard, /billing, /admin
|
||||
5. Créer la table profiles
|
||||
6. Créer automatiquement un enregistrement dans la table profiles après inscription réussie
|
||||
7. La table profiles doit contenir les champs email, role, plan
|
||||
|
||||
Exigences de mise en œuvre :
|
||||
- Indiquez à chaque étape quels fichiers sont modifiés
|
||||
- Ne pas coder en dur les clés secrètes
|
||||
- Marquez clairement les opérations à effectuer manuellement dans la console Supabase
|
||||
- Expliquez comment vérifier l'inscription et la connexion une fois terminé
|
||||
```
|
||||
|
||||
### 3.2 Intégrer l'interface de génération et la base de données
|
||||
|
||||
```text
|
||||
Considérez que je suis débutant et aidez-moi à réaliser la fonctionnalité principale du site : générer du copywriting marketing et le sauvegarder.
|
||||
|
||||
Résultat attendu :
|
||||
1. L'utilisateur remplit le formulaire sur /dashboard et clique sur « Générer le copywriting »
|
||||
2. Le backend reçoit : nom du produit, description, utilisateurs cibles, arguments de vente, canaux de distribution
|
||||
3. Le backend appelle le modèle pour générer le résultat
|
||||
4. La page affiche le résultat de la génération
|
||||
5. Les entrées et sorties sont sauvegardées dans la base de données
|
||||
6. L'utilisateur peut consulter son historique lors de sa prochaine visite
|
||||
|
||||
J'ai besoin que vous réalisiez :
|
||||
- Créer l'interface de génération /api/generate
|
||||
- Créer la table generations
|
||||
- Concevoir les champs d'entrée et de sortie
|
||||
- La page Dashboard lit l'historique de l'utilisateur actuel
|
||||
|
||||
Expérience utilisateur :
|
||||
- État de chargement du bouton
|
||||
- Message d'erreur en cas d'échec de la génération
|
||||
- État vide en l'absence d'historique
|
||||
|
||||
Une fois terminé, veuillez indiquer :
|
||||
- L'emplacement des fichiers de pages frontend
|
||||
- L'emplacement des fichiers d'interfaces backend
|
||||
- L'emplacement de la logique d'écriture en base de données
|
||||
- Comment tester la chaîne de génération complète
|
||||
```
|
||||
|
||||
### 3.3 Intégrer le paiement Stripe
|
||||
|
||||
```text
|
||||
Considérez que je suis débutant et aidez-moi à ajouter un paiement Stripe minimal et fonctionnel au site.
|
||||
|
||||
Pas besoin d'un système complexe, faites d'abord fonctionner la chaîne de paiement la plus basique.
|
||||
|
||||
J'ai besoin que vous réalisiez :
|
||||
1. La page /billing affiche les forfaits free et pro
|
||||
2. L'utilisateur est redirigé vers Stripe Checkout après clic sur la mise à niveau
|
||||
3. Retour sur le site après paiement réussi
|
||||
4. Le résultat du paiement est sauvegardé dans la table subscriptions
|
||||
5. Mise à jour synchrone du champ profile.plan
|
||||
6. Limitation des utilisateurs free à 3 générations par jour, pas de limite pour les utilisateurs pro
|
||||
|
||||
Principes de mise en œuvre :
|
||||
- Faites d'abord fonctionner le flux principal, ne vous préoccupez pas des cas limites complexes
|
||||
- Indiquez clairement ce qui doit être configuré dans la console Stripe
|
||||
- Expliquez comment tester le processus de paiement complet une fois terminé
|
||||
```
|
||||
|
||||
### 3.4 Construire la console d'administration
|
||||
|
||||
```text
|
||||
Considérez que je suis débutant et aidez-moi à créer une console d'administration simple et fonctionnelle.
|
||||
|
||||
Accès réservé aux administrateurs uniquement.
|
||||
|
||||
J'ai besoin que vous réalisiez :
|
||||
1. Seuls les utilisateurs avec role = admin peuvent accéder à /admin
|
||||
2. La console comprend 3 onglets : liste des utilisateurs, enregistrements de génération, statut des abonnements
|
||||
3. La liste des utilisateurs affiche : email, plan, date de création
|
||||
4. Les enregistrements de génération affichent : utilisateur, nom du produit, canal, date de création
|
||||
5. Le statut des abonnements affiche : utilisateur, forfait, statut du paiement
|
||||
|
||||
Exigences :
|
||||
- Interface simple et claire
|
||||
- Utiliser les composants existants (tableaux, onglets, badges) de la bibliothèque de composants
|
||||
- Expliquez comment définir un compte comme administrateur une fois terminé
|
||||
```
|
||||
|
||||
### Bloqué ?
|
||||
|
||||
Si vous êtes bloqué lors du développement backend, vous pouvez consulter ces chapitres :
|
||||
|
||||
- [De la base de données à Supabase](../../backend/database-supabase/)
|
||||
- [Conception et développement d'interfaces backend d'application](../../backend/ai-interface-code/)
|
||||
- [Comment intégrer un système de paiement comme Stripe](../../backend/stripe-payment/)
|
||||
|
||||
## Partie 4 : Tests de bout en bout et déploiement
|
||||
|
||||
### 4.1 Tests de bout en bout
|
||||
|
||||
Vérifiez au moins les scénarios suivants :
|
||||
|
||||
- Inscription -> Connexion -> Génération de copywriting -> Consultation de l'historique -> Mise à niveau du forfait
|
||||
- Connexion administrateur -> Consultation des données utilisateurs -> Consultation des enregistrements de génération -> Consultation du statut des paiements
|
||||
|
||||
Vérifications avant déploiement :
|
||||
|
||||
```text
|
||||
Considérez que je suis débutant et aidez-moi à vérifier si le projet est prêt pour le déploiement.
|
||||
|
||||
Points de vérification :
|
||||
- Les variables d'environnement sont-elles complètes
|
||||
- L'URL de callback de connexion est-elle correcte
|
||||
- L'URL de callback de paiement Stripe est-elle correcte
|
||||
- Les pages ont-elles des états de chargement, des états vides et des messages d'erreur
|
||||
- Le README contient-il les instructions de démarrage et de déploiement
|
||||
|
||||
J'ai besoin que vous :
|
||||
1. Listiez les éléments à corriger par ordre de priorité
|
||||
2. Indiquiez ceux qui doivent être corrigés en premier
|
||||
3. Expliquiez les étapes de déploiement après correction
|
||||
```
|
||||
|
||||
### 4.2 Déploiement
|
||||
|
||||
Déployez le projet dans un environnement public. Tutoriel de déploiement : [Flux de travail Git et GitHub](../../backend/git-workflow/), [Comment déployer une application web](../../backend/zeabur-deployment/).
|
||||
|
||||
## Livrables
|
||||
|
||||
Après avoir terminé ce projet, vous devez soumettre les éléments suivants :
|
||||
|
||||
- [ ] Lien de démonstration en ligne accessible
|
||||
- [ ] Lien du dépôt de code source (avec README)
|
||||
- [ ] Document PRD
|
||||
- [ ] Captures d'écran des pages principales (accueil, Dashboard, Billing, Admin)
|
||||
- [ ] Vidéo de démonstration de 60 secondes (couvrant inscription -> génération -> paiement -> console d'administration)
|
||||
|
||||
Le README doit contenir au minimum : présentation du projet, description des pages principales, stack technique, étapes de démarrage local, liste des variables d'environnement.
|
||||
|
||||
## Critères d'évaluation
|
||||
|
||||
| Dimension | Exigences de base | Exigences avancées |
|
||||
|------|---------|---------|
|
||||
| Complétude du produit | Accueil, connexion, Dashboard, Billing, Admin sont tous accessibles | Le copywriting et le style visuel de l'accueil ressemblent à un véritable SaaS |
|
||||
| Boucle métier | Inscription -> Connexion -> Génération -> Historique fonctionne | La différence de permissions entre Free/Pro est clairement visible |
|
||||
| Exactitude des données | Les résultats de génération et le statut des paiements sont écrits dans la base de données | Il y a des messages d'erreur clairs, des états vides et des états de chargement |
|
||||
| Permissions et sécurité | Les utilisateurs non connectés ne peuvent pas accéder aux pages protégées, les utilisateurs ordinaires ne peuvent pas accéder à l'Admin | Il y a une validation basique des entrées et une authentification côté serveur |
|
||||
| Livraison du projet | Le projet peut être lancé localement et déployé sur le web public | Le README est clair, la vidéo de démonstration est structurée |
|
||||
|
||||
::: tip
|
||||
Si vous trouvez la tâche trop importante, rappelez-vous ce principe : **Assurez-vous d'abord que « ça fonctionne », puis cherchez à « le rendre beau ».**
|
||||
:::
|
||||
|
||||
## Vérification avant soumission
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">Dernier coup d'œil avant de soumettre</div>
|
||||
</template>
|
||||
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> L'accueil, la page de connexion, le Dashboard, le Billing et l'Admin sont terminés</label></li>
|
||||
<li><label><input type="checkbox" disabled /> L'utilisateur peut s'inscrire, se connecter et se déconnecter</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Les résultats de génération sont réellement écrits dans la base de données</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Le processus principal de paiement fonctionne</label></li>
|
||||
<li><label><input type="checkbox" disabled /> L'administrateur peut voir les utilisateurs, les enregistrements de génération et le statut des paiements</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Le projet est déployé sur le web public</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## Ressources de référence
|
||||
|
||||
- [Conception UI](../../frontend/ui-design/)
|
||||
- [Concevoir des pages et des boutons en référence aux guidelines de conception UI](../../frontend/multi-product-ui/)
|
||||
- [Rendre l'interface attrayante avec les LLM et les Skills](../../frontend/llm-skills-beautiful/)
|
||||
- [Du prototype de conception au code de projet](../../frontend/design-to-code/)
|
||||
- [Mettre à jour votre interface avec une bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
- [De la base de données à Supabase](../../backend/database-supabase/)
|
||||
- [Conception et développement d'interfaces backend d'application](../../backend/ai-interface-code/)
|
||||
- [Flux de travail Git et GitHub](../../backend/git-workflow/)
|
||||
- [Comment déployer une application web](../../backend/zeabur-deployment/)
|
||||
- [Comment intégrer un système de paiement comme Stripe](../../backend/stripe-payment/)
|
||||
@@ -0,0 +1,180 @@
|
||||
# Développement pratique d'une plateforme d'agents IA de type Dify
|
||||
|
||||
## Aperçu
|
||||
|
||||
Ce projet pratique vous demande de réaliser, à partir d'un véritable PRD, une plateforme d'agents IA reproduisant l'expérience centrale de Dify. Vous construirez une console utilisateur, un back-office administrateur et un backend de plateforme, en implémentant les fonctionnalités principales de gestion d'agents, de conversation, de journalisation et de base de connaissances.
|
||||
|
||||
Il s'agit du projet pratique synthétique de l'Étape 2. Contrairement aux projets précédents portant sur une seule page ou une seule fonctionnalité, ce projet vous demande de construire un produit IA avec une véritable dimension de plateforme, comprenant plusieurs rôles, plusieurs modules, la persistance des données et une chaîne d'appels de modèles.
|
||||
|
||||
## Prérequis
|
||||
|
||||
Avant de commencer ce projet, vous devriez maîtriser les éléments suivants :
|
||||
|
||||
- Conception de pages frontales et utilisation de bibliothèques de composants ([Conception UI](../../frontend/ui-design/), [Bibliothèque de composants moderne](../../frontend/modern-component-library/))
|
||||
- Conception et développement d'API backend ([Écriture de code d'interface](../../backend/ai-interface-code/))
|
||||
- Bases de données et Supabase ([Des bases de données à Supabase](../../backend/database-supabase/))
|
||||
- Flux de travail Git et déploiement ([Git et GitHub](../../backend/git-workflow/), [Déployer une application web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Objectifs d'apprentissage
|
||||
|
||||
Après avoir terminé ce projet, vous serez capable de :
|
||||
|
||||
1. Lire et comprendre un véritable PRD et en extraire une liste de tâches de développement
|
||||
2. Concevoir l'architecture des pages et le modèle de données d'une plateforme d'agents
|
||||
3. Implémenter le flux complet de création d'agents, de conversation et de journalisation
|
||||
4. Utiliser l'IA pour vous aider à développer un produit de type plateforme
|
||||
5. Effectuer des tests de bout en bout et livrer un prototype de plateforme IA démontrable
|
||||
|
||||
## Présentation du projet
|
||||
|
||||
Le produit que vous allez construire est une plateforme d'agents IA de type Dify, comprenant deux sous-systèmes :
|
||||
|
||||
| Sous-système | Responsabilité |
|
||||
|--------|------|
|
||||
| **Console utilisateur** | Créer des agents, configurer les prompts, lancer des conversations, consulter les journaux, gérer la base de connaissances |
|
||||
| **Back-office administrateur** | Consulter les données utilisateurs, l'utilisation des ressources de la plateforme et les statistiques d'appels |
|
||||
|
||||
Le backend doit prendre en charge les capacités principales suivantes : gestion des agents, gestion des sessions, stockage des messages, appels de modèles, journalisation des appels et intégration de la base de connaissances.
|
||||
|
||||
::: tip Accès au PRD
|
||||
Le document d'exigences de ce projet se trouve sur GitHub : [Voir le PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/fr-fr/stage-2/assignments/custom-dify-agent-platform/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Analyse des besoins', description: 'Lire le PRD, clarifier les pages, les limites de capacités, l\'authentification et le modèle de données' },
|
||||
{ title: 'Construction du squelette', description: 'Générer avec l\'IA le squelette de la console utilisateur et du back-office' },
|
||||
{ title: 'Développement itératif', description: 'Compléter module par module : agents, conversations, journaux, base de connaissances' },
|
||||
{ title: 'Tests et mise en ligne', description: 'Tests de bout en bout, déploiement et préparation de la démonstration' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Partie 1 : Analyse des besoins
|
||||
|
||||
### 1.1 Lire le PRD
|
||||
|
||||
Ouvrez le document PRD et répondez aux questions suivantes :
|
||||
|
||||
- Parmi les agents, les sessions, les journaux et la base de connaissances, lesquels doivent figurer dans le MVP ?
|
||||
- La liste des pages et des routes est-elle finalisée ?
|
||||
- Quelles sont les limites des appels de modèles et de la journalisation ?
|
||||
- Le multi-locataire et les flux de travail complexes doivent-ils être exclus dans un premier temps ?
|
||||
|
||||
::: warning
|
||||
Si les questions ci-dessus n'ont pas de réponse claire, ne commencez pas à coder. Une mauvaise compréhension des besoins est la cause la plus fréquente de retour en arrière.
|
||||
:::
|
||||
|
||||
### 1.2 Confirmer l'architecture du système
|
||||
|
||||
À partir du PRD, dégagez l'architecture globale du système :
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> app["Console utilisateur"]
|
||||
prd --> admin["Back-office administrateur"]
|
||||
app --> auth["Authentification"]
|
||||
app --> agent["Configuration des agents"]
|
||||
app --> chat["Sessions de conversation"]
|
||||
chat --> llm["Appels de modèles"]
|
||||
chat --> db["Base de données"]
|
||||
app --> kb["Intégration de la base de connaissances"]
|
||||
admin --> logs["Journaux d'appels et vue d'ensemble de la plateforme"]
|
||||
logs --> db
|
||||
```
|
||||
|
||||
## Partie 2 : Construction du squelette du projet
|
||||
|
||||
### 2.1 Générer les pages frontales
|
||||
|
||||
Prompt de référence :
|
||||
|
||||
```text
|
||||
Veuillez générer, sur la base du PRD actuel, le squelette frontend d'une plateforme d'agents IA de type Dify.
|
||||
|
||||
Exigences :
|
||||
1. Côté utilisateur : connexion, liste des agents, configuration des agents, page de conversation, page des journaux, page de la base de connaissances
|
||||
2. Côté back-office : accueil du back-office, vue d'ensemble des utilisateurs, vue d'ensemble de l'utilisation des ressources
|
||||
3. Générer d'abord uniquement la structure des pages et des données fictives, sans connexion à une API réelle
|
||||
4. Le style doit ressembler à une plateforme IA moderne
|
||||
```
|
||||
|
||||
### 2.2 Vérifier la structure des pages
|
||||
|
||||
Vérifiez point par point :
|
||||
|
||||
- [ ] Les routes de la console utilisateur et du back-office sont-elles séparées ?
|
||||
- [ ] La liste des agents, la page de configuration, la conversation et les journaux sont-ils complets ?
|
||||
- [ ] Le back-office dispose-t-il de la vue d'ensemble des utilisateurs et des ressources ?
|
||||
|
||||
## Partie 3 : Développement itératif
|
||||
|
||||
### 3.1 Progresser par module
|
||||
|
||||
1. **Authentification** : Inscription, connexion, authentification de session
|
||||
2. **Gestion des agents** : Créer, modifier, supprimer des agents, configurer les prompts système
|
||||
3. **Conversations** : Envoyer des messages, recevoir des réponses du modèle, historique des conversations
|
||||
4. **Base de connaissances** : Uploader des documents, lier un agent à une base de connaissances
|
||||
5. **Journalisation** : Enregistrer chaque appel de modèle (prompt, réponse, durée, tokens)
|
||||
6. **Back-office** : Statistiques d'utilisation, vue d'ensemble des ressources
|
||||
|
||||
### 3.2 Modèle de données de référence
|
||||
|
||||
Tables principales :
|
||||
|
||||
- `agents` : id, user_id, name, system_prompt, model, created_at
|
||||
- `conversations` : id, agent_id, user_id, created_at
|
||||
- `messages` : id, conversation_id, role, content, created_at
|
||||
- `knowledge_bases` : id, agent_id, name, created_at
|
||||
- `call_logs` : id, agent_id, conversation_id, model, prompt_tokens, completion_tokens, latency_ms, created_at
|
||||
|
||||
## Partie 4 : Tests et mise en ligne
|
||||
|
||||
### 4.1 Tests de bout en bout
|
||||
|
||||
Vérifiez au minimum les scénarios suivants :
|
||||
|
||||
- Créer un agent -> Lancer une conversation -> Consulter les journaux
|
||||
- Uploader un document dans la base de connaissances -> Vérifier que l'agent peut l'utiliser
|
||||
- Consulter les statistiques du back-office
|
||||
|
||||
### 4.2 Déploiement
|
||||
|
||||
- Déployer le frontend sur Vercel / Zeabur
|
||||
- Déployer le backend sur Zeabur / Railway / Render
|
||||
- Utiliser Supabase comme base de données
|
||||
|
||||
Vérifications avant déploiement :
|
||||
|
||||
- [ ] Les variables d'environnement sont-elles toutes configurées ?
|
||||
- [ ] L'authentification fonctionne-t-elle correctement en production ?
|
||||
- [ ] Les appels de modèles fonctionnent-ils correctement ?
|
||||
|
||||
## Livrables
|
||||
|
||||
Après avoir terminé ce projet, vous devez soumettre les éléments suivants :
|
||||
|
||||
- [ ] Un lien de démonstration en ligne accessible
|
||||
- [ ] Un lien vers le dépôt de code source (avec README)
|
||||
- [ ] Le document PRD
|
||||
- [ ] Des captures d'écran des pages principales
|
||||
- [ ] Une vidéo de démonstration de 60 secondes
|
||||
|
||||
## Critères d'évaluation
|
||||
|
||||
| Dimension | Exigences de base | Exigences avancées |
|
||||
|------|---------|---------|
|
||||
| Boucle des agents | Créer un agent, lancer une conversation, voir les journaux | La base de connaissances est intégrée et les agents peuvent l'utiliser |
|
||||
| Plateforme | Console utilisateur et back-office sont accessibles | Les journaux d'appels et les statistiques sont complets |
|
||||
| Technique | Le backend peut appeler des modèles et stocker les résultats | Gestion des erreurs et optimisation des performances |
|
||||
| Livraison | Le projet peut être exécuté et déployé | README clair et vidéo de démonstration |
|
||||
|
||||
## Références
|
||||
|
||||
- [Conception UI](../../frontend/ui-design/)
|
||||
- [Bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
- [Des bases de données à Supabase](../../backend/database-supabase/)
|
||||
- [Écriture de code d'interface assistée par IA](../../backend/ai-interface-code/)
|
||||
- [Flux de travail Git et GitHub](../../backend/git-workflow/)
|
||||
- [Comment déployer une application web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,306 @@
|
||||
# Développement pratique d'un système de gestion d'examens en ligne
|
||||
|
||||
## Aperçu
|
||||
|
||||
Ce projet pratique vous demande de réaliser, à partir d'un véritable PRD (document d'exigences produit), un système de gestion d'examens en ligne complet, depuis zéro. La particularité de ce projet est qu'il comprend plusieurs rôles (étudiants et administrateurs), chacun voyant des pages différentes et pouvant exécuter des opérations différentes. Vous utiliserez Express pour construire le backend et implémenter le flux métier complet des examens.
|
||||
|
||||
Il s'agit du projet pratique synthétique de l'Étape 2. Les systèmes multi-rôles avec gestion des permissions sont très courants en milieu professionnel. Une fois ce modèle maîtrisé, vous pourrez faire face à de nombreux scénarios métier tels que la formation en ligne, les plateformes SaaS ou les back-office administratifs.
|
||||
|
||||
## Prérequis
|
||||
|
||||
Avant de commencer ce projet, vous devriez maîtriser les éléments suivants :
|
||||
|
||||
- Conception de pages frontales et utilisation de bibliothèques de composants ([Conception UI](../../frontend/ui-design/), [Bibliothèque de composants moderne](../../frontend/modern-component-library/))
|
||||
- Conception et développement d'API backend ([Écriture de code d'interface](../../backend/ai-interface-code/))
|
||||
- Bases de données et Supabase ([Des bases de données à Supabase](../../backend/database-supabase/))
|
||||
- Flux de travail Git et déploiement ([Git et GitHub](../../backend/git-workflow/), [Déployer une application web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Objectifs d'apprentissage
|
||||
|
||||
Après avoir terminé ce projet, vous serez capable de :
|
||||
|
||||
1. Lire et comprendre un véritable PRD, et en extraire une liste de tâches de développement
|
||||
2. Concevoir le contrôle des permissions et le routage des pages pour un système multi-rôles
|
||||
3. Implémenter une API backend complète avec Express
|
||||
4. Réaliser le flux métier complet : examen, soumission, notation automatique
|
||||
5. Effectuer des tests de bout en bout et livrer un prototype de système métier démontrable
|
||||
|
||||
## Présentation du projet
|
||||
|
||||
Le produit que vous allez construire est un système de gestion d'examens en ligne, comprenant trois sous-systèmes :
|
||||
|
||||
| Sous-système | Responsabilité |
|
||||
|--------|------|
|
||||
| **Site vitrine** | Présentation de la plateforme, point d'accès de connexion |
|
||||
| **Portail étudiant** | Liste des examens, passage des épreuves, soumission, consultation des notes |
|
||||
| **Back-office admin** | Gestion de la banque de questions, gestion des examens, enregistrement des soumissions, statistiques des résultats |
|
||||
|
||||
Le backend utilise Express et doit prendre en charge : l'authentification, la gestion des rôles et permissions, la gestion des examens et de la banque de questions, le processus de soumission et la notation automatique, ainsi que la gestion des notes et des statistiques.
|
||||
|
||||
::: tip Accès au PRD
|
||||
Le document d'exigences de ce projet se trouve sur GitHub : [Voir le PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/fr-fr/stage-2/assignments/exam-management-express/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Analyse des besoins', description: 'Lire le PRD, clarifier les rôles, les pages, le flux des examens et le modèle de données' },
|
||||
{ title: 'Construction du squelette', description: 'Générer avec l\'IA le squelette des pages étudiant et admin' },
|
||||
{ title: 'Développement backend', description: 'Connecter avec Express : connexion, examens, soumission, notation' },
|
||||
{ title: 'Tests et mise en ligne', description: 'Tests de bout en bout, déploiement et préparation de la démonstration' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Partie 1 : Analyse des besoins
|
||||
|
||||
### 1.1 Lire le PRD
|
||||
|
||||
Ouvrez le document PRD et répondez aux questions suivantes :
|
||||
|
||||
- Quels rôles le système comprend-il ? Que peuvent-ils faire respectivement ?
|
||||
- La liste des pages est-elle complète ? Quelles pages le portail étudiant et le back-office admin comportent-ils ?
|
||||
- Quels types de questions sont pris en charge ? Quelle est la logique de notation pour chaque type ?
|
||||
- Quel est le flux complet d'un examen ? (Publication -> Démarrage -> Réponse -> Soumission -> Notation -> Consultation des résultats)
|
||||
|
||||
::: warning
|
||||
Si les questions ci-dessus n'ont pas de réponse claire, ne commencez pas à coder. Une mauvaise compréhension des besoins est la cause la plus fréquente de retour en arrière.
|
||||
:::
|
||||
|
||||
### 1.2 Confirmer l'architecture du système
|
||||
|
||||
À partir du PRD, dégagez l'architecture globale du système :
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["Site vitrine"]
|
||||
prd --> student["Portail étudiant"]
|
||||
prd --> admin["Back-office admin"]
|
||||
student --> auth["Authentification"]
|
||||
student --> exam["Examens et réponses"]
|
||||
exam --> db["Base de données"]
|
||||
admin --> question["Gestion de la banque de questions"]
|
||||
admin --> submission["Enregistrement des soumissions et statistiques"]
|
||||
question --> db
|
||||
submission --> db
|
||||
```
|
||||
|
||||
## Partie 2 : Construction du squelette du projet
|
||||
|
||||
### 2.1 Générer les pages frontales
|
||||
|
||||
Prompt de référence :
|
||||
|
||||
```text
|
||||
Veuillez générer, sur la base du PRD actuel, le squelette frontend d'un système de gestion d'examens en ligne.
|
||||
|
||||
Stack technique requise :
|
||||
- Next.js App Router
|
||||
- TypeScript
|
||||
- Tailwind CSS
|
||||
- shadcn/ui
|
||||
|
||||
Liste des pages :
|
||||
1. Page d'accueil /
|
||||
2. Page de connexion /login
|
||||
3. Liste des examens (étudiant) /student/exams
|
||||
4. Page de passage d'examen /student/exams/[id]
|
||||
5. Page des résultats (étudiant) /student/history
|
||||
6. Accueil du back-office admin /admin
|
||||
7. Gestion des examens /admin/exams
|
||||
8. Gestion de la banque de questions /admin/questions
|
||||
9. Enregistrement des soumissions /admin/submissions
|
||||
|
||||
Exigences :
|
||||
- Les pages étudiant doivent être claires, concentrées et faciles à utiliser
|
||||
- Les pages admin doivent utiliser une mise en page avec barre latérale + barre supérieure
|
||||
- Utiliser d'abord des données mock, sans connexion à une API réelle
|
||||
- Assurer une utilisation de base correcte sur desktop et mobile
|
||||
```
|
||||
|
||||
### 2.2 Améliorer la page de passage d'examen
|
||||
|
||||
La page de passage d'examen est la page centrale du portail étudiant. À améliorer en priorité :
|
||||
|
||||
```text
|
||||
Veuillez continuer à améliorer la page de passage d'examen.
|
||||
|
||||
Il s'agit de la page de passage d'un examen en ligne, elle doit contenir :
|
||||
- En haut : titre de l'examen, compte à rebours, nombre de questions déjà répondues
|
||||
- Au centre : énoncé de la question et options
|
||||
- Prise en charge de trois types de questions : choix unique, vrai/faux, réponse courte
|
||||
- À gauche ou en haut : cartographie des réponses, indiquant si chaque question a été répondue
|
||||
- Avant la soumission, afficher une boîte de confirmation
|
||||
|
||||
Implémenter d'abord les interactions avec des données mock, sans connexion à une API réelle.
|
||||
|
||||
Exigences :
|
||||
- Interface épurée, ne pas ressembler à une page de back-office
|
||||
- Le compte à rebours doit être visible sans être trop oppressant
|
||||
- Prévoir un état vide et un état de chargement
|
||||
```
|
||||
|
||||
### 2.3 Améliorer le back-office administrateur
|
||||
|
||||
La première version du back-office admin se concentre sur trois zones principales :
|
||||
|
||||
- **Gestion des examens** : Créer un examen, définir la durée, gérer le statut de publication
|
||||
- **Gestion de la banque de questions** : Ajouter des questions, modifier des questions, filtrer par type
|
||||
- **Enregistrement des soumissions** : Voir les soumissions des étudiants, les scores, les durées
|
||||
|
||||
### 2.4 Vérifier la structure des pages
|
||||
|
||||
Vérifiez point par point :
|
||||
|
||||
- [ ] Les points d'accès du portail étudiant et du back-office admin sont-ils séparés ?
|
||||
- [ ] La page de connexion, la liste des examens, la page de passage d'examen et la page des résultats sont-elles complètes ?
|
||||
- [ ] Les pages de gestion de la banque de questions, des examens et des enregistrements de soumission du back-office sont-elles accessibles ?
|
||||
- [ ] Le style visuel des pages étudiant et admin est-il clairement différencié ?
|
||||
|
||||
### Vous êtes bloqué ?
|
||||
|
||||
Si vous êtes bloqué lors de la construction du frontend, vous pouvez consulter ces chapitres :
|
||||
|
||||
- [Des bases de données à Supabase](../../backend/database-supabase/)
|
||||
- [Écriture de code d'interface assistée par IA](../../backend/ai-interface-code/)
|
||||
- [Mettre à jour votre interface avec une bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
|
||||
## Partie 3 : Développement backend
|
||||
|
||||
### 3.1 Connexion et contrôle des permissions
|
||||
|
||||
```text
|
||||
Considérez que je suis débutant et aidez-moi à mettre en place la connexion et le contrôle des permissions du système d'examens en ligne.
|
||||
|
||||
Le backend utilise Express.
|
||||
|
||||
Objectifs :
|
||||
1. Les étudiants et les administrateurs peuvent tous les deux se connecter
|
||||
2. Après connexion, le rôle de l'utilisateur est renvoyé
|
||||
3. Les étudiants ne peuvent accéder qu'aux routes /student/*
|
||||
4. Les administrateurs ne peuvent accéder qu'aux routes /admin/*
|
||||
5. Les utilisateurs non connectés sont redirigés vers /login lorsqu'ils accèdent à une page protégée
|
||||
|
||||
Exigences d'implémentation :
|
||||
- Proposer une structure de répertoire claire
|
||||
- Expliquer clairement la responsabilité du middleware
|
||||
- Ne pas coder en dur les variables d'environnement
|
||||
- Après implémentation, expliquer comment vérifier que les permissions fonctionnent
|
||||
```
|
||||
|
||||
### 3.2 API de gestion des examens et de la banque de questions
|
||||
|
||||
Il est recommandé d'implémenter les modules suivants :
|
||||
|
||||
| Module | API recommandées |
|
||||
|------|----------|
|
||||
| Gestion des examens | `GET /api/exams`, `POST /api/admin/exams`, `PATCH /api/admin/exams/:id` |
|
||||
| Gestion de la banque de questions | `GET /api/admin/questions`, `POST /api/admin/questions` |
|
||||
| Démarrer un examen | `POST /api/submissions/start` |
|
||||
| Soumettre une copie | `POST /api/submissions/:id/submit` |
|
||||
| Enregistrement des résultats | `GET /api/student/history`, `GET /api/admin/submissions` |
|
||||
|
||||
Prompt de référence :
|
||||
|
||||
```text
|
||||
Veuillez concevoir et implémenter l'API Express pour le système d'examens en ligne.
|
||||
|
||||
Périmètre fonctionnel :
|
||||
- L'administrateur crée des examens
|
||||
- L'administrateur gère la banque de questions
|
||||
- L'étudiant consulte les examens publiés
|
||||
- L'étudiant commence un examen et crée une soumission
|
||||
- L'étudiant soumet ses réponses et la notation automatique est effectuée pour les QCM et les questions vrai/faux
|
||||
- Les questions à réponse courte sont d'abord marquées comme en attente de révision
|
||||
- L'étudiant consulte ses résultats historiques
|
||||
- L'administrateur consulte tous les enregistrements de soumission
|
||||
|
||||
Exigences :
|
||||
- Nommage clair des API
|
||||
- Retourner une structure JSON unifiée
|
||||
- Séparer clairement les couches controller, service, middleware et db dans le code
|
||||
- Expliquer comment tester chaque API
|
||||
```
|
||||
|
||||
### 3.3 Logique de notation
|
||||
|
||||
La logique de notation est la règle métier essentielle du système d'examens :
|
||||
|
||||
- **Questions à choix unique** : La réponse de l'utilisateur est correcte si elle correspond à la réponse attendue
|
||||
- **Questions vrai/faux** : La notation automatique est également possible
|
||||
- **Questions à réponse courte** : Dans la première version, seule la réponse est enregistrée, le score est vide, et le statut est `reviewed = false`
|
||||
|
||||
::: tip Bonus
|
||||
Si vous souhaitez ajouter des capacités IA, vous pouvez permettre à l'administrateur de saisir un "thème + niveau de difficulté" dans le back-office, puis laisser le modèle générer d'abord un ensemble de questions candidates, qui seront ensuite validées manuellement avant d'être intégrées à la banque. Il s'agit cependant d'un bonus, pas d'une obligation.
|
||||
:::
|
||||
|
||||
## Partie 4 : Tests et mise en ligne
|
||||
|
||||
### 4.1 Tests de bout en bout
|
||||
|
||||
Vérifiez au minimum les scénarios suivants :
|
||||
|
||||
- Étudiant : connexion -> consultation de la liste des examens -> démarrage d'un examen -> soumission -> consultation des résultats
|
||||
- Administrateur : connexion -> création d'un examen -> ajout de questions -> publication -> consultation des enregistrements de soumission
|
||||
|
||||
### 4.2 Déploiement
|
||||
|
||||
- Déployer le frontend sur Vercel / Zeabur
|
||||
- Déployer l'API Express sur Zeabur / Railway / Render
|
||||
- Utiliser Supabase Postgres ou un PostgreSQL hébergé comme base de données
|
||||
|
||||
Vérifications avant déploiement :
|
||||
|
||||
- [ ] Les variables d'environnement sont-elles toutes configurées ?
|
||||
- [ ] Les adresses API frontend/backend sont-elles correctes ?
|
||||
- [ ] L'état de connexion fonctionne-t-il correctement en production ?
|
||||
- [ ] Le compte administrateur peut-il réellement accéder au back-office ?
|
||||
- [ ] Le README contient-il les instructions de démarrage, de déploiement et de test ?
|
||||
|
||||
## Livrables
|
||||
|
||||
Après avoir terminé ce projet, vous devez soumettre les éléments suivants :
|
||||
|
||||
- [ ] Un lien de démonstration en ligne accessible
|
||||
- [ ] Un lien vers le dépôt de code source (avec README)
|
||||
- [ ] Le document PRD
|
||||
- [ ] Des captures d'écran des pages principales (accueil, liste des examens étudiant, page de passage d'examen, back-office admin)
|
||||
- [ ] Une vidéo de démonstration de 60 secondes (couvrant le flux de réponse de l'étudiant et le flux de gestion de l'administrateur)
|
||||
|
||||
Le README doit contenir au minimum : la présentation du projet, la description des pages principales, la stack technique, les étapes de démarrage local et la liste des variables d'environnement.
|
||||
|
||||
## Critères d'évaluation
|
||||
|
||||
| Dimension | Exigences de base | Exigences avancées |
|
||||
|------|---------|---------|
|
||||
| Complétude des pages | Les pages principales du portail étudiant et du back-office admin sont accessibles | Le style des pages est cohérent et l'utilisation mobile est correcte |
|
||||
| Boucle métier | L'étudiant peut se connecter, passer un examen, soumettre et voir ses résultats | L'administrateur peut créer et publier un examen de bout en bout |
|
||||
| Exactitude des données | Les réponses soumises sont écrites dans la base de données et les questions objectives sont notées automatiquement | Les questions à réponse courte prennent en charge la révision manuelle ou l'assistance IA |
|
||||
| Contrôle des permissions | La séparation des accès entre étudiants et administrateurs est claire | Les API côté serveur ont également une vérification des rôles |
|
||||
| Livraison technique | Le projet peut être exécuté, déployé et le README est clair | Il y a une vidéo de démonstration et des instructions de test |
|
||||
|
||||
## Vérification avant soumission
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">Dernier regard avant de soumettre</div>
|
||||
</template>
|
||||
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> Les pages d'accueil, de connexion, du portail étudiant et du back-office admin sont toutes terminées</label></li>
|
||||
<li><label><input type="checkbox" disabled /> L'étudiant peut démarrer un examen et soumettre ses réponses normalement</label></li>
|
||||
<li><label><input type="checkbox" disabled /> L'administrateur peut créer un examen et voir les enregistrements de soumission</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Les scores des questions objectives sont calculés automatiquement et écrits dans la base de données</label></li>
|
||||
<li><label><input type="checkbox" disabled /> La séparation des permissions entre étudiants et administrateurs a été vérifiée</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Le projet est déployé ou dispose d'instructions complètes d'exécution locale</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## Références
|
||||
|
||||
- [Conception UI](../../frontend/ui-design/)
|
||||
- [Mettre à jour votre interface avec une bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
- [Des bases de données à Supabase](../../backend/database-supabase/)
|
||||
- [Écriture de code d'interface assistée par IA](../../backend/ai-interface-code/)
|
||||
- [Flux de travail Git et GitHub](../../backend/git-workflow/)
|
||||
- [Comment déployer une application web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,211 @@
|
||||
# Développement pratique d'une SaaS de génération d'images IA moderne
|
||||
|
||||
## Aperçu
|
||||
|
||||
Ce projet pratique vous demande de réaliser, à partir d'un véritable PRD (document d'exigences produit), une SaaS de génération d'images IA inspirée de l'expérience Midjourney. Vous passerez par l'ensemble du processus : analyse des besoins, décomposition du projet, développement itératif et mise en ligne.
|
||||
|
||||
Il s'agit du projet pratique synthétique de l'Étape 2. Dans les chapitres précédents, vous avez appris séparément la conception de pages frontend, le développement d'API backend, les opérations sur les bases de données et l'intégration de paiements. Ce projet vous demande de tout assembler pour livrer un prototype de produit fonctionnel.
|
||||
|
||||
## Prérequis
|
||||
|
||||
Avant de commencer ce projet, vous devriez maîtriser les éléments suivants :
|
||||
|
||||
- Conception de pages frontales et utilisation de bibliothèques de composants ([Conception UI](../../frontend/ui-design/), [Bibliothèque de composants moderne](../../frontend/modern-component-library/))
|
||||
- Conception et développement d'API backend ([Écriture de code d'interface](../../backend/ai-interface-code/))
|
||||
- Bases de données et Supabase ([Des bases de données à Supabase](../../backend/database-supabase/))
|
||||
- Intégration de paiements ([Système de paiement Stripe](../../backend/stripe-payment/))
|
||||
- Flux de travail Git et déploiement ([Git et GitHub](../../backend/git-workflow/), [Déployer une application web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Objectifs d'apprentissage
|
||||
|
||||
Après avoir terminé ce projet, vous serez capable de :
|
||||
|
||||
1. Lire et comprendre un véritable PRD et en extraire une liste de tâches de développement
|
||||
2. Décomposer les modules à partir du PRD et établir un plan de progression par étapes
|
||||
3. Utiliser l'IA pour vous aider à construire le squelette frontend et développer les API backend
|
||||
4. Valider et optimiser de manière itérative chaque module
|
||||
5. Effectuer des tests de bout en bout et faire passer le projet du stade « fonctionnel » à « livrable »
|
||||
|
||||
## Présentation du projet
|
||||
|
||||
Le produit que vous allez construire est une plateforme SaaS de génération d'images IA moderne, comprenant trois sous-systèmes :
|
||||
|
||||
| Sous-système | Responsabilité |
|
||||
|--------|------|
|
||||
| **Site vitrine** | Présentation du produit, tarification, FAQ, conversion des inscriptions |
|
||||
| **Espace de travail utilisateur** | Saisie de prompts, génération d'images, galerie, crédits, forfaits, interactions communautaires |
|
||||
| **Back-office administrateur** | Gestion des utilisateurs, des tâches, des paiements, modération du contenu, indicateurs SaaS, surveillance système |
|
||||
|
||||
Le backend doit prendre en charge les capacités principales suivantes : authentification des utilisateurs, tâches de génération d'images, stockage objet OSS, paiement par crédits et forfaits, interactions sociales autour des images et surveillance des données opérationnelles.
|
||||
|
||||
::: tip Accès au PRD
|
||||
Le document d'exigences de ce projet se trouve sur GitHub : [Voir le PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/fr-fr/stage-2/assignments/modern-landing-page/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Analyse des besoins', description: 'Lire le PRD, extraire les pages, modules, modèles de données et limites' },
|
||||
{ title: 'Construction du squelette', description: 'Générer avec l\'IA trois squelettes frontend (www / app / admin)' },
|
||||
{ title: 'Développement itératif', description: 'Compléter module par module : API, permissions, paiement, surveillance' },
|
||||
{ title: 'Tests et mise en ligne', description: 'Tests de bout en bout, déploiement et préparation de la démonstration' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Partie 1 : Analyse des besoins
|
||||
|
||||
### 1.1 Lire le PRD
|
||||
|
||||
Ouvrez le document PRD et répondez aux questions suivantes :
|
||||
|
||||
- Combien le système a-t-il de points d'accès ? Quelles pages chaque point couvre-t-il ?
|
||||
- Quelle est la fonctionnalité principale de chaque page ?
|
||||
- Quels modules et tables de données le backend comprend-il ?
|
||||
- Quelle est la portée du MVP ? Que fait-on dans la première version, que laisse-t-on de côté ?
|
||||
|
||||
::: warning
|
||||
Si les questions ci-dessus n'ont pas de réponse claire, ne commencez pas à coder. Une mauvaise compréhension des besoins est la cause la plus fréquente de retour en arrière.
|
||||
:::
|
||||
|
||||
### 1.2 Confirmer l'architecture du système
|
||||
|
||||
À partir de la description du PRD, dégagez l'architecture globale du système :
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["Site vitrine"]
|
||||
prd --> app["Espace de travail utilisateur"]
|
||||
prd --> admin["Back-office administrateur"]
|
||||
app --> auth["Authentification"]
|
||||
app --> gen["Tâches de génération d'images"]
|
||||
gen --> oss["Stockage objet OSS"]
|
||||
gen --> db["Base de données"]
|
||||
billing["Paiement et forfaits"] --> db
|
||||
social["Partage / Likes / Commentaires / Reposts"] --> db
|
||||
admin --> analytics["Tableau de bord des indicateurs SaaS"]
|
||||
admin --> observability["Surveillance API / DB / Provider"]
|
||||
```
|
||||
|
||||
Il est recommandé de redessiner le diagramme d'architecture vous-même pour confirmer que votre compréhension du système est complète.
|
||||
|
||||
## Partie 2 : Construction du squelette du projet
|
||||
|
||||
### 2.1 Générer les pages frontales
|
||||
|
||||
Utilisez l'IA pour générer d'abord la structure de base et les données fictives de toutes les pages. L'objectif de cette étape est de mettre en place l'architecture de l'information et le routage, sans connexion à une API réelle.
|
||||
|
||||
Prompt de référence :
|
||||
|
||||
```text
|
||||
Veuillez générer, sur la base du PRD actuel, le squelette frontend d'une SaaS de génération d'images IA moderne.
|
||||
|
||||
Exigences :
|
||||
1. Divisé en trois points d'accès : www, app, admin
|
||||
2. Le site vitrine comprend : page d'accueil, tarification, FAQ
|
||||
3. L'app comprend : connexion, inscription, espace de génération, galerie, forfaits, crédits, communauté, détails des œuvres, profil utilisateur
|
||||
4. L'admin comprend : accueil du back-office, gestion des utilisateurs, gestion des tâches, gestion du contenu, gestion des forfaits, commandes de paiement, configuration opérationnelle, indicateurs SaaS, surveillance système
|
||||
5. Générer d'abord uniquement la structure des pages et des données fictives, sans connexion à une API réelle
|
||||
6. Style inspiré de Midjourney : épuré, moderne, avec une sensation produit
|
||||
```
|
||||
|
||||
### 2.2 Vérifier la structure des pages
|
||||
|
||||
Après la génération du squelette, vérifiez point par point :
|
||||
|
||||
- [ ] Les routes des trois points d'accès sont-elles indépendantes (`/`, `/app`, `/admin`) ?
|
||||
- [ ] Le nombre de pages correspond-il au PRD ?
|
||||
- [ ] Chaque page est-elle accessible et navigable normalement ?
|
||||
- [ ] Les données fictives montrent-elles les états UI de base (listes, états vides, formulaires, etc.) ?
|
||||
|
||||
## Partie 3 : Développement itératif
|
||||
|
||||
### 3.1 Progresser par module
|
||||
|
||||
Sur la base du squelette, complétez les fonctionnalités module par module dans l'ordre suivant :
|
||||
|
||||
1. **Authentification** : Inscription, connexion, distinction des rôles
|
||||
2. **Base de données** : Création des tables de données, API de lecture/écriture
|
||||
3. **Cœur du métier** : Tâches de génération d'images, stockage des résultats
|
||||
4. **Stockage OSS** : Upload et accès aux images
|
||||
5. **Paiement** : Forfaits, crédits, intégration Stripe
|
||||
6. **Interactions sociales** : Partage, likes, commentaires
|
||||
7. **Back-office** : Gestion des utilisateurs, des tâches, modération du contenu
|
||||
8. **Surveillance des données** : Tableau de bord des indicateurs SaaS, surveillance système
|
||||
|
||||
Après chaque module terminé, effectuez une auto-vérification à l'aide du tableau suivant :
|
||||
|
||||
| Point de contrôle | Méthode de vérification |
|
||||
|--------|----------|
|
||||
| Cohérence des pages | Le nombre de pages, les points d'accès et les fonctionnalités correspondent-ils au PRD ? |
|
||||
| Exactitude des API | Les paramètres de requête, la structure de retour et la gestion des statuts sont-ils raisonnables ? |
|
||||
| Isolation des permissions | Les utilisateurs normaux et les administrateurs sont-ils correctement isolés ? |
|
||||
| Cohérence des données | La base de données, le stockage OSS, les paiements et les crédits sont-ils cohérents ? |
|
||||
| Démontrabilité | Pouvez-vous démontrer un flux métier complet à quelqu'un ? |
|
||||
|
||||
::: tip
|
||||
Si vous constatez que le contenu généré par l'IA s'écarte du PRD, ne repartez pas de zéro pour toute la page. Demandez-lui simplement de modifier le module spécifique concerné.
|
||||
:::
|
||||
|
||||
### 3.2 Rôles et responsabilités
|
||||
|
||||
Au cours du développement itératif, vous devez jouer trois rôles simultanément :
|
||||
|
||||
- **Chef de produit** : Confirmer que les fonctionnalités de chaque module correspondent au PRD
|
||||
- **Responsable technique** : Confirmer que la solution d'implémentation est raisonnable
|
||||
- **Ingénieur de test** : Confirmer que les fonctionnalités fonctionnent correctement
|
||||
|
||||
## Partie 4 : Tests et mise en ligne
|
||||
|
||||
### 4.1 Tests de bout en bout
|
||||
|
||||
L'accent dans la phase finale n'est pas sur l'ajout de nouvelles pages, mais sur la validation complète des flux métier. Vérifiez au minimum les scénarios suivants :
|
||||
|
||||
- Inscription -> Achat de crédits -> Génération d'images -> Consultation de l'historique -> Interactions sociales
|
||||
- Connexion administrateur -> Consultation des données utilisateurs -> Consultation des statistiques de tâches -> Consultation de la surveillance système
|
||||
|
||||
### 4.2 Déploiement
|
||||
|
||||
Déployez le projet dans un environnement public et assurez-vous que :
|
||||
|
||||
- Les variables d'environnement sont entièrement configurées
|
||||
- L'URL de callback de connexion est correcte
|
||||
- L'URL de callback de paiement est correcte
|
||||
- Aucune page ne présente d'états de chargement, vides ou d'erreurs manquants
|
||||
|
||||
Tutoriel de déploiement : [Flux de travail Git et GitHub](../../backend/git-workflow/), [Comment déployer une application web](../../backend/zeabur-deployment/).
|
||||
|
||||
## Livrables
|
||||
|
||||
Après avoir terminé ce projet, vous devez soumettre les éléments suivants :
|
||||
|
||||
- [ ] Un lien de démonstration en ligne accessible
|
||||
- [ ] Un lien vers le dépôt de code source (avec README)
|
||||
- [ ] Le document PRD
|
||||
- [ ] Des captures d'écran des pages principales (accueil du site vitrine, espace de génération, galerie, page des forfaits, accueil du back-office)
|
||||
- [ ] Une vidéo de démonstration de 60 secondes (couvrant : inscription -> génération -> consultation -> back-office admin)
|
||||
|
||||
Le README doit contenir au minimum : la présentation du projet, la description des pages principales, la stack technique, les étapes de démarrage local et la liste des variables d'environnement.
|
||||
|
||||
## Critères d'évaluation
|
||||
|
||||
| Dimension | Exigences de base | Exigences avancées |
|
||||
|------|---------|---------|
|
||||
| Alignement PRD | Pages, fonctionnalités et structures de données globalement conformes au PRD | Chaque décision de design peut être clairement reliée au PRD |
|
||||
| Boucle produit | Inscription -> Achat de crédits -> Génération d'images -> Historique -> Interactions sociales fonctionne | État des paiements, solde des crédits et nombre de générations sont cohérents |
|
||||
| Capacités du back-office | Gestion des utilisateurs, des tâches, des paiements et du contenu est visible | Le tableau de bord des indicateurs SaaS et la page de surveillance système sont complets et fonctionnels |
|
||||
| Complétude technique | Frontend, backend, base de données, OSS et chaîne de paiement sont connectés | Gestion des erreurs, états vides et états de chargement sont présents |
|
||||
| Qualité de livraison | Peut être déployé et exécuté | README clair, vidéo de démonstration bien structurée |
|
||||
|
||||
## Références
|
||||
|
||||
- [Conception UI](../../frontend/ui-design/)
|
||||
- [Concevoir des pages et des boutons en référençant les guidelines UI](../../frontend/multi-product-ui/)
|
||||
- [Rendre les interfaces attrayantes avec les LLM et les Skills](../../frontend/llm-skills-beautiful/)
|
||||
- [Du prototype de design au code de projet](../../frontend/design-to-code/)
|
||||
- [Mettre à jour votre interface avec une bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
- [Des bases de données à Supabase](../../backend/database-supabase/)
|
||||
- [Écriture de code d'interface assistée par IA](../../backend/ai-interface-code/)
|
||||
- [Flux de travail Git et GitHub](../../backend/git-workflow/)
|
||||
- [Comment déployer une application web](../../backend/zeabur-deployment/)
|
||||
- [Comment intégrer Stripe et d'autres systèmes de paiement](../../backend/stripe-payment/)
|
||||
@@ -0,0 +1,151 @@
|
||||
# Développement pratique d'un système de recommandation de films avec Spring Boot
|
||||
|
||||
## Aperçu
|
||||
|
||||
Ce projet pratique vous demande de réaliser, à partir d'un véritable PRD, un site web de films avec capacités de recommandation en utilisant Spring Boot. Le défi principal de ce projet est qu'il ne s'agit pas d'un simple CRUD, mais qu'il vous amène à réfléchir à la manière dont les comportements des utilisateurs influencent les résultats de recommandation et à rendre ces recommandations explicables.
|
||||
|
||||
Il s'agit du projet pratique synthétique de l'Étape 2. Vous découvrirez pour la première fois le modèle de développement de produits de type « contenu + comportement + recommandation », très courant dans le e-commerce, les plateformes de contenu et les flux personnalisés.
|
||||
|
||||
## Prérequis
|
||||
|
||||
Avant de commencer ce projet, vous devriez maîtriser les éléments suivants :
|
||||
|
||||
- Conception de pages frontales et utilisation de bibliothèques de composants ([Conception UI](../../frontend/ui-design/), [Bibliothèque de composants moderne](../../frontend/modern-component-library/))
|
||||
- Conception et développement d'API backend ([Écriture de code d'interface](../../backend/ai-interface-code/))
|
||||
- Bases de données et Supabase ([Des bases de données à Supabase](../../backend/database-supabase/))
|
||||
- Flux de travail Git et déploiement ([Git et GitHub](../../backend/git-workflow/), [Déployer une application web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Objectifs d'apprentissage
|
||||
|
||||
Après avoir terminé ce projet, vous serez capable de :
|
||||
|
||||
1. Lire un PRD et en extraire une liste de tâches de développement pour un système de recommandation
|
||||
2. Utiliser Spring Boot pour mettre en place un projet backend et implémenter des API RESTful
|
||||
3. Concevoir le flux de données complet « comportement utilisateur -> recommandation »
|
||||
4. Implémenter une logique de recommandation explicable
|
||||
5. Effectuer des tests de bout en bout et livrer un prototype de produit démontrable
|
||||
|
||||
## Présentation du projet
|
||||
|
||||
Le produit que vous allez construire est un site web de films avec capacités de recommandation :
|
||||
|
||||
| Fonctionnalité | Description |
|
||||
|------|------|
|
||||
| **Navigation et recherche** | Les utilisateurs peuvent parcourir et rechercher des films |
|
||||
| **Notes et favoris** | Les utilisateurs peuvent noter des films et les ajouter aux favoris |
|
||||
| **Recommandations personnalisées** | Le système génère des recommandations basées sur le comportement des utilisateurs |
|
||||
| **Back-office** | Les administrateurs gèrent les données des films et consultent l'efficacité des recommandations |
|
||||
|
||||
::: tip Accès au PRD
|
||||
Le document d'exigences de ce projet se trouve sur GitHub : [Voir le PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/fr-fr/stage-2/assignments/movie-recommendation-springboot/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Analyse des besoins', description: 'Lire le PRD, clarifier la stratégie de recommandation, les données comportementales et le périmètre du back-office' },
|
||||
{ title: 'Construction du squelette', description: 'Générer avec l\'IA le squelette des pages liste, détails, recommandations et back-office' },
|
||||
{ title: 'Développement itératif', description: 'Compléter la logique de recommandation, l\'enregistrement des comportements et la gestion du back-office' },
|
||||
{ title: 'Tests et mise en ligne', description: 'Tests de bout en bout, déploiement et préparation de la démonstration' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Partie 1 : Analyse des besoins
|
||||
|
||||
### 1.1 Lire le PRD
|
||||
|
||||
Ouvrez le document PRD et répondez aux questions suivantes :
|
||||
|
||||
- Quels comportements utilisateur sont suivis (notes, favoris, historique de visualisation) ?
|
||||
- Quelle est la stratégie de recommandation (filtrage collaboratif, basée sur le contenu, hybride) ?
|
||||
- Comment les recommandations sont-elles rendues explicables pour l'utilisateur ?
|
||||
- Quelles sont les fonctionnalités du MVP ?
|
||||
|
||||
::: warning
|
||||
Si les questions ci-dessus n'ont pas de réponse claire, ne commencez pas à coder. Une mauvaise compréhension des besoins est la cause la plus fréquente de retour en arrière.
|
||||
:::
|
||||
|
||||
## Partie 2 : Construction du squelette du projet
|
||||
|
||||
### 2.1 Générer les pages frontales
|
||||
|
||||
Prompt de référence :
|
||||
|
||||
```text
|
||||
Veuillez générer, sur la base du PRD actuel, le squelette frontend d'un site web de films avec système de recommandation.
|
||||
|
||||
Exigences :
|
||||
1. Page d'accueil avec films populaires et recommandations personnalisées
|
||||
2. Page de liste de films avec recherche et filtrage
|
||||
3. Page de détail d'un film avec notes et avis
|
||||
4. Page de profil avec favoris et historique
|
||||
5. Back-office pour la gestion des films et le suivi des recommandations
|
||||
6. Générer d'abord uniquement la structure des pages et des données fictives
|
||||
```
|
||||
|
||||
### 2.2 Vérifier la structure des pages
|
||||
|
||||
- [ ] La page d'accueil affiche-t-elle les recommandations ?
|
||||
- [ ] La page de détail permet-elle de noter et d'ajouter aux favoris ?
|
||||
- [ ] Le back-office permet-il la gestion des films ?
|
||||
|
||||
## Partie 3 : Développement itératif
|
||||
|
||||
### 3.1 Progresser par module
|
||||
|
||||
1. **Gestion des films** : CRUD des films, recherche et filtrage
|
||||
2. **Notes et favoris** : Les utilisateurs peuvent noter et sauvegarder des films
|
||||
3. **Suivi des comportements** : Enregistrement des notes, favoris et historique de navigation
|
||||
4. **Logique de recommandation** : Algorithme de recommandation basé sur les comportements
|
||||
5. **Explicabilité** : Afficher pourquoi un film est recommandé (ex: « Recommandé car vous avez aimé X »)
|
||||
6. **Back-office** : Gestion des films et suivi de l'efficacité des recommandations
|
||||
|
||||
### 3.2 Modèle de données de référence
|
||||
|
||||
Tables principales :
|
||||
|
||||
- `movies` : id, title, genre, description, release_year, rating_avg
|
||||
- `user_ratings` : id, user_id, movie_id, rating, created_at
|
||||
- `user_favorites` : id, user_id, movie_id, created_at
|
||||
- `user_views` : id, user_id, movie_id, viewed_at
|
||||
- `recommendations` : id, user_id, movie_id, reason, score, created_at
|
||||
|
||||
## Partie 4 : Tests et mise en ligne
|
||||
|
||||
### 4.1 Tests de bout en bout
|
||||
|
||||
- Parcourir les films -> Noter un film -> Voir les recommandations mises à jour
|
||||
- Ajouter aux favoris -> Vérifier que les recommandations en tiennent compte
|
||||
|
||||
### 4.2 Déploiement
|
||||
|
||||
- Déployer le frontend sur Vercel / Zeabur
|
||||
- Déployer le backend Spring Boot sur Zeabur / Railway / Render
|
||||
- Utiliser Supabase ou PostgreSQL comme base de données
|
||||
|
||||
## Livrables
|
||||
|
||||
- [ ] Un lien de démonstration en ligne accessible
|
||||
- [ ] Un lien vers le dépôt de code source (avec README)
|
||||
- [ ] Le document PRD
|
||||
- [ ] Des captures d'écran des pages principales
|
||||
- [ ] Une vidéo de démonstration de 60 secondes
|
||||
|
||||
## Critères d'évaluation
|
||||
|
||||
| Dimension | Exigences de base | Exigences avancées |
|
||||
|------|---------|---------|
|
||||
| Films | Navigation, recherche, détails fonctionnent | Les notes et favoris sont sauvegardés |
|
||||
| Recommandation | Des recommandations sont affichées | Elles sont basées sur le comportement et sont explicables |
|
||||
| Technique | Spring Boot fonctionne avec la base de données | Gestion des erreurs et optimisation des performances |
|
||||
| Livraison | Le projet peut être exécuté et déployé | README clair et vidéo de démonstration |
|
||||
|
||||
## Références
|
||||
|
||||
- [Conception UI](../../frontend/ui-design/)
|
||||
- [Bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
- [Des bases de données à Supabase](../../backend/database-supabase/)
|
||||
- [Écriture de code d'interface assistée par IA](../../backend/ai-interface-code/)
|
||||
- [Flux de travail Git et GitHub](../../backend/git-workflow/)
|
||||
- [Comment déployer une application web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,166 @@
|
||||
# Développement pratique d'un système de microservices pour l'e-commerce de produits frais
|
||||
|
||||
## Aperçu
|
||||
|
||||
Ce projet pratique vous demande de réaliser, à partir d'un véritable PRD, un système de microservices pour l'e-commerce de produits frais. Contrairement aux projets précédents basés sur un seul service, le backend de ce projet est découpé en plusieurs services indépendants selon le domaine métier, communiquant via une passerelle API unifiée. Vous apprendrez à concevoir les limites des services et à gérer la cohérence des données entre services.
|
||||
|
||||
Il s'agit du projet pratique synthétique de l'Étape 2. L'architecture microservices est très courante en milieu professionnel. Une fois les principes de découpage des services et de routage par passerelle maîtrisés, vous serez en mesure de concevoir des systèmes backend plus complexes.
|
||||
|
||||
## Prérequis
|
||||
|
||||
Avant de commencer ce projet, vous devriez maîtriser les éléments suivants :
|
||||
|
||||
- Conception de pages frontales et utilisation de bibliothèques de composants ([Conception UI](../../frontend/ui-design/), [Bibliothèque de composants moderne](../../frontend/modern-component-library/))
|
||||
- Conception et développement d'API backend ([Écriture de code d'interface](../../backend/ai-interface-code/))
|
||||
- Bases de données et Supabase ([Des bases de données à Supabase](../../backend/database-supabase/))
|
||||
- Flux de travail Git et déploiement ([Git et GitHub](../../backend/git-workflow/), [Déployer une application web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Objectifs d'apprentissage
|
||||
|
||||
Après avoir terminé ce projet, vous serez capable de :
|
||||
|
||||
1. Lire un PRD et en extraire une liste de tâches de développement pour un système de microservices
|
||||
2. Découper les limites des services par domaine métier (authentification, catalogue, inventaire, commandes)
|
||||
3. Concevoir et implémenter le routage d'une passerelle API
|
||||
4. Gérer les problèmes inter-services tels que la décrémentation de stock et la cohérence des commandes
|
||||
5. Effectuer des tests de bout en bout et livrer un prototype de microservices démontrable
|
||||
|
||||
## Présentation du projet
|
||||
|
||||
Le produit que vous allez construire est un système de microservices pour l'e-commerce de produits frais :
|
||||
|
||||
| Sous-système | Responsabilité |
|
||||
|--------|------|
|
||||
| **Portail client** | Parcourir les produits, passer des commandes, consulter les commandes |
|
||||
| **Portail gestion** | Gestion des produits, gestion des stocks, gestion des commandes |
|
||||
|
||||
Le backend est découpé en services par domaine métier :
|
||||
|
||||
| Service | Responsabilité |
|
||||
|------|------|
|
||||
| **Passerelle API** | Point d'entrée unique, routage, validation de l'authentification |
|
||||
| **Service d'authentification** | Inscription, connexion, émission de JWT |
|
||||
| **Service catalogue** | Gestion des informations produits |
|
||||
| **Service inventaire** | Gestion des quantités en stock |
|
||||
| **Service de commandes** | Création et gestion du statut des commandes |
|
||||
|
||||
::: tip Accès au PRD
|
||||
Le document d'exigences de ce projet se trouve sur GitHub : [Voir le PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/fr-fr/stage-2/assignments/simple-grocery-microservices/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Analyse des besoins', description: 'Lire le PRD, clarifier la découpe des services, les API et la cohérence des données' },
|
||||
{ title: 'Construction du squelette', description: 'Générer avec l\'IA le squelette de la passerelle et des services de base' },
|
||||
{ title: 'Développement itératif', description: 'Compléter les services un par un : auth, catalogue, inventaire, commandes' },
|
||||
{ title: 'Tests et mise en ligne', description: 'Tests de bout en bout, déploiement et préparation de la démonstration' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Partie 1 : Analyse des besoins
|
||||
|
||||
### 1.1 Lire le PRD
|
||||
|
||||
Ouvrez le document PRD et répondez aux questions suivantes :
|
||||
|
||||
- Comment les services sont-ils découpés ? Chaque service a-t-il sa propre base de données ?
|
||||
- Comment la passerelle API route-t-elle les requêtes vers les services concernés ?
|
||||
- Comment gérer la cohérence entre la décrémentation de stock et la création de commande ?
|
||||
- Quelles sont les fonctionnalités du MVP ?
|
||||
|
||||
::: warning
|
||||
Si les questions ci-dessus n'ont pas de réponse claire, ne commencez pas à coder. Une mauvaise compréhension des besoins est la cause la plus fréquente de retour en arrière.
|
||||
:::
|
||||
|
||||
### 1.2 Confirmer l'architecture du système
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
client["Client"] --> gateway["Passerelle API"]
|
||||
gateway --> auth["Service d'authentification"]
|
||||
gateway --> catalog["Service catalogue"]
|
||||
gateway --> inventory["Service inventaire"]
|
||||
gateway --> order["Service de commandes"]
|
||||
catalog --> db1["DB Catalogue"]
|
||||
inventory --> db2["DB Inventaire"]
|
||||
order --> db3["DB Commandes"]
|
||||
auth --> db4["DB Auth"]
|
||||
```
|
||||
|
||||
## Partie 2 : Construction du squelette du projet
|
||||
|
||||
### 2.1 Générer les pages frontales
|
||||
|
||||
Prompt de référence :
|
||||
|
||||
```text
|
||||
Veuillez générer, sur la base du PRD actuel, le squelette frontend d'un système e-commerce de produits frais.
|
||||
|
||||
Exigences :
|
||||
1. Portail client : liste des produits, panier, page de commande, historique des commandes
|
||||
2. Portail gestion : gestion des produits, gestion des stocks, gestion des commandes
|
||||
3. Générer d'abord uniquement la structure des pages et des données fictives
|
||||
```
|
||||
|
||||
### 2.2 Vérifier la structure des pages
|
||||
|
||||
- [ ] Le portail client et le portail gestion sont-ils séparés ?
|
||||
- [ ] La liste des produits, le panier et les commandes fonctionnent-ils ?
|
||||
- [ ] Le portail gestion permet-il de gérer les produits et les stocks ?
|
||||
|
||||
## Partie 3 : Développement itératif
|
||||
|
||||
### 3.1 Progresser par service
|
||||
|
||||
1. **Passerelle API** : Routage des requêtes, validation JWT
|
||||
2. **Service d'authentification** : Inscription, connexion, émission de tokens
|
||||
3. **Service catalogue** : CRUD des produits, recherche
|
||||
4. **Service inventaire** : Suivi des stocks, décrémentation lors des commandes
|
||||
5. **Service de commandes** : Création de commandes, suivi du statut, historique
|
||||
|
||||
### 3.2 Points d'attention inter-services
|
||||
|
||||
- **Cohérence des stocks** : Lorsqu'une commande est créée, le stock doit être décrémenté de manière fiable
|
||||
- **Communication entre services** : Utiliser des appels API synchrones ou des événements asynchrones
|
||||
- **Gestion des erreurs** : Que se passe-t-il si le service d'inventaire est indisponible lors d'une commande ?
|
||||
|
||||
## Partie 4 : Tests et mise en ligne
|
||||
|
||||
### 4.1 Tests de bout en bout
|
||||
|
||||
- Parcourir les produits -> Ajouter au panier -> Commander -> Vérifier la mise à jour du stock
|
||||
- Gestion : Ajouter un produit -> Vérifier qu'il apparaît côté client
|
||||
|
||||
### 4.2 Déploiement
|
||||
|
||||
- Déployer chaque service indépendamment sur Zeabur / Railway / Render
|
||||
- Configurer la passerelle API pour router vers les services déployés
|
||||
- Utiliser des bases de données séparées ou Supabase avec des schémas distincts
|
||||
|
||||
## Livrables
|
||||
|
||||
- [ ] Un lien de démonstration en ligne accessible
|
||||
- [ ] Un lien vers le dépôt de code source (avec README)
|
||||
- [ ] Le document PRD
|
||||
- [ ] Des captures d'écran des pages principales
|
||||
- [ ] Une vidéo de démonstration de 60 secondes
|
||||
|
||||
## Critères d'évaluation
|
||||
|
||||
| Dimension | Exigences de base | Exigences avancées |
|
||||
|------|---------|---------|
|
||||
| Services | L'authentification et le catalogue fonctionnent | L'inventaire et les commandes sont connectés |
|
||||
| Passerelle | Les requêtes sont correctement routées | La validation JWT est opérationnelle |
|
||||
| Technique | Chaque service peut être démarré indépendamment | La cohérence inter-services est gérée |
|
||||
| Livraison | Le projet peut être exécuté et déployé | README clair et vidéo de démonstration |
|
||||
|
||||
## Références
|
||||
|
||||
- [Conception UI](../../frontend/ui-design/)
|
||||
- [Bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
- [Des bases de données à Supabase](../../backend/database-supabase/)
|
||||
- [Écriture de code d'interface assistée par IA](../../backend/ai-interface-code/)
|
||||
- [Flux de travail Git et GitHub](../../backend/git-workflow/)
|
||||
- [Comment déployer une application web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,163 @@
|
||||
# Développement pratique d'une plateforme d'analyse de données de transport en Go
|
||||
|
||||
## Aperçu
|
||||
|
||||
Ce projet pratique vous demande de réaliser, à partir d'un véritable PRD, une plateforme d'analyse de données de transport en utilisant Go. Contrairement aux projets précédents de type CRUD, vous allez construire une chaîne de données complète : « ingestion de données → agrégation → alertes → visualisation ». Ce type de produit de données est très courant dans les scénarios IoT, la supervision et l'analyse opérationnelle.
|
||||
|
||||
Il s'agit du projet pratique synthétique de l'Étape 2, et c'est également votre premier contact avec le langage Go. Rassurez-vous, avec les bases en JavaScript / TypeScript acquises précédemment, l'apprentissage de Go n'est pas difficile — l'essentiel est de comprendre la logique de conception de la chaîne de données.
|
||||
|
||||
## Prérequis
|
||||
|
||||
Avant de commencer ce projet, vous devriez maîtriser les éléments suivants :
|
||||
|
||||
- Conception de pages frontales et utilisation de bibliothèques de composants ([Conception UI](../../frontend/ui-design/), [Bibliothèque de composants moderne](../../frontend/modern-component-library/))
|
||||
- Conception et développement d'API backend ([Écriture de code d'interface](../../backend/ai-interface-code/))
|
||||
- Bases de données et Supabase ([Des bases de données à Supabase](../../backend/database-supabase/))
|
||||
- Flux de travail Git et déploiement ([Git et GitHub](../../backend/git-workflow/), [Déployer une application web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Objectifs d'apprentissage
|
||||
|
||||
Après avoir terminé ce projet, vous serez capable de :
|
||||
|
||||
1. Lire un PRD et en extraire une liste de tâches de développement pour un produit de données
|
||||
2. Utiliser Go (Gin ou Fiber) pour mettre en place un service d'API backend
|
||||
3. Concevoir une chaîne complète d'ingestion de données, d'agrégation par fenêtre temporelle et d'alertes
|
||||
4. Maintenir la cohérence entre les données backend et le tableau de bord frontend
|
||||
5. Effectuer des tests de bout en bout et livrer un prototype de produit de données démontrable
|
||||
|
||||
## Présentation du projet
|
||||
|
||||
Le produit que vous allez construire est une plateforme d'analyse de données de transport en Go :
|
||||
|
||||
| Module | Responsabilité |
|
||||
|------|------|
|
||||
| **Ingestion de données** | Réceptionner les événements de transport bruts et les stocker en base |
|
||||
| **Agrégation de données** | Calculer les tendances et indicateurs de congestion par fenêtre temporelle |
|
||||
| **Alertes** | Générer des enregistrements d'alerte basés sur des règles |
|
||||
| **Tableau de bord** | Afficher les graphiques de tendances, les classements et la liste des alertes |
|
||||
|
||||
::: tip Accès au PRD
|
||||
Le document d'exigences de ce projet se trouve sur GitHub : [Voir le PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/fr-fr/stage-2/assignments/traffic-data-visualization-go/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Analyse des besoins', description: 'Lire le PRD, clarifier les sources de données, les définitions des indicateurs et les règles d\'alerte' },
|
||||
{ title: 'Construction du squelette', description: 'Générer avec l\'IA le service Go API et le squelette du tableau de bord frontend' },
|
||||
{ title: 'Développement itératif', description: 'Compléter la logique d\'agrégation, les règles d\'alerte et les API du tableau de bord' },
|
||||
{ title: 'Tests et mise en ligne', description: 'Tests de bout en bout, déploiement et préparation de la démonstration' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Partie 1 : Analyse des besoins
|
||||
|
||||
### 1.1 Lire le PRD
|
||||
|
||||
Ouvrez le document PRD et répondez aux questions suivantes :
|
||||
|
||||
- Quelle est la source des données ? Quels sont les champs disponibles ?
|
||||
- Quelle est la définition des indicateurs clés ? (par exemple, le critère exact de « congestion »)
|
||||
- Quelles sont les règles d'alerte ? Faut-il se limiter à des règles simples dans la première version ?
|
||||
- Quelles pages et graphiques le tableau de bord doit-il contenir ?
|
||||
|
||||
::: warning
|
||||
Si les questions ci-dessus n'ont pas de réponse claire, ne commencez pas à coder. Une mauvaise compréhension des besoins est la cause la plus fréquente de retour en arrière.
|
||||
:::
|
||||
|
||||
### 1.2 Confirmer la chaîne de données
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> ingest["API d'ingestion de données"]
|
||||
ingest --> raw["Table de données brutes"]
|
||||
raw --> agg["Tâches d'agrégation"]
|
||||
agg --> alert["Règles d'alerte"]
|
||||
agg --> dashboard["API du tableau de bord"]
|
||||
alert --> dashboard
|
||||
```
|
||||
|
||||
## Partie 2 : Construction du squelette du projet
|
||||
|
||||
### 2.1 Générer le service d'API Go
|
||||
|
||||
Prompt de référence :
|
||||
|
||||
```text
|
||||
Veuillez générer, sur la base du PRD actuel, le squelette d'une plateforme d'analyse de données de transport en Go.
|
||||
|
||||
Exigences :
|
||||
1. Utiliser Gin ou Fiber
|
||||
2. Fournir une API d'ingestion de données
|
||||
3. Fournir le squelette des tâches d'agrégation
|
||||
4. Fournir le squelette des API dashboard et alerts
|
||||
5. Ne pas implémenter d'analyse complexe réelle, se limiter à une structure exécutable
|
||||
```
|
||||
|
||||
### 2.2 Vérifier la structure du projet
|
||||
|
||||
Vérifiez point par point :
|
||||
|
||||
- [ ] Le service Go démarre correctement
|
||||
- [ ] L'API d'ingestion peut recevoir et stocker des données
|
||||
- [ ] Le framework des tâches d'agrégation est en place
|
||||
- [ ] Les pages du tableau de bord frontend affichent des graphiques de base
|
||||
|
||||
## Partie 3 : Développement itératif
|
||||
|
||||
### 3.1 Progresser par module
|
||||
|
||||
1. **API d'ingestion de données** : Recevoir les événements de transport bruts et les écrire en base de données
|
||||
2. **Agrégation de données** : Agréger par fenêtre temporelle, calculer les tendances et indicateurs de congestion
|
||||
3. **Règles d'alerte** : Générer des enregistrements d'alerte basés sur des seuils
|
||||
4. **API du tableau de bord** : Fournir les données de tendances, de classement et la liste des alertes
|
||||
5. **Tableau de bord frontend** : Graphiques de tendances, classements, page de liste des alertes
|
||||
|
||||
### 3.2 Auto-vérification par module
|
||||
|
||||
| Point de contrôle | Méthode de vérification |
|
||||
|--------|----------|
|
||||
| Ingestion de données | Les données brutes sont-elles correctement stockées en base |
|
||||
| Définition des agrégations | La logique de calcul des tendances et classements est-elle cohérente |
|
||||
| Règles d'alerte | Les conditions de déclenchement correspondent-elles aux attentes |
|
||||
| Cohérence des données | L'affichage du tableau de bord correspond-il aux données backend |
|
||||
| Conformité des API | Y a-t-il une structure de retour unifiée et une gestion des erreurs |
|
||||
|
||||
## Partie 4 : Tests et mise en ligne
|
||||
|
||||
### 4.1 Tests de bout en bout
|
||||
|
||||
Vérifiez au minimum les scénarios suivants :
|
||||
|
||||
- Ingestion d'un jeu de données de test → Exécution des tâches d'agrégation → Mise à jour de l'affichage du tableau de bord
|
||||
- Déclenchement d'une condition d'alerte → Génération d'un enregistrement d'alerte → Affichage sur la page des alertes
|
||||
|
||||
## Livrables
|
||||
|
||||
Après avoir terminé ce projet, vous devez soumettre les éléments suivants :
|
||||
|
||||
- [ ] Un lien de démonstration en ligne accessible
|
||||
- [ ] Un lien vers le dépôt de code source (avec README)
|
||||
- [ ] Le document PRD
|
||||
- [ ] Des captures d'écran des pages principales (démonstration d'ingestion, tableau de bord des tendances, liste des alertes)
|
||||
- [ ] Une vidéo de démonstration de 60 secondes
|
||||
|
||||
## Critères d'évaluation
|
||||
|
||||
| Dimension | Exigences de base | Exigences avancées |
|
||||
|------|---------|---------|
|
||||
| Alignement PRD | Les fonctionnalités et structures de données sont globalement conformes au PRD | Les définitions des indicateurs et la logique d'agrégation sont clairement expliquées |
|
||||
| Chaîne de données | Ingestion → Agrégation → Alertes → Tableau de bord fonctionnel | Les tâches d'agrégation supportent les mises à jour incrémentales |
|
||||
| Capacités d'analyse | Les trois modules tendances, classement et alertes sont opérationnels | Les indicateurs sont configurables et les règles d'alerte personnalisables |
|
||||
| Affichage frontend | Le tableau de bord affiche des graphiques de base | Les graphiques supportent le filtrage par plage de dates |
|
||||
| Complétude technique | L'API Go, la base de données et la chaîne frontend sont connectées | L'API dispose d'une gestion des erreurs et de journaux unifiés |
|
||||
|
||||
## Références
|
||||
|
||||
- [Conception UI](../../frontend/ui-design/)
|
||||
- [Bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
- [Des bases de données à Supabase](../../backend/database-supabase/)
|
||||
- [Écriture de code d'interface assistée par IA](../../backend/ai-interface-code/)
|
||||
- [Flux de travail Git et GitHub](../../backend/git-workflow/)
|
||||
- [Comment déployer une application web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,162 @@
|
||||
# Développement pratique d'une plateforme Agent de planification de voyages intelligente
|
||||
|
||||
## Aperçu
|
||||
|
||||
Ce projet pratique vous demande de réaliser, à partir d'un véritable PRD, une plateforme Agent de planification de voyages intelligente. Vous construirez un produit IA complet capable de recevoir des entrées structurées, de générer des itinéraires journaliers et de prendre en charge la sauvegarde et la réutilisation. Il ne s'agit pas d'un simple chatbot, mais d'un produit doté de capacités de gestion de tâches.
|
||||
|
||||
Il s'agit du projet pratique synthétique de l'Étape 2. Le défi principal de ce projet est de faire en sorte que l'IA génère des itinéraires structurés et exploitables, et non un long bloc de texte non manipulable.
|
||||
|
||||
## Prérequis
|
||||
|
||||
Avant de commencer ce projet, vous devriez maîtriser les éléments suivants :
|
||||
|
||||
- Conception de pages frontales et utilisation de bibliothèques de composants ([Conception UI](../../frontend/ui-design/), [Bibliothèque de composants moderne](../../frontend/modern-component-library/))
|
||||
- Conception et développement d'API backend ([Écriture de code d'interface](../../backend/ai-interface-code/))
|
||||
- Bases de données et Supabase ([Des bases de données à Supabase](../../backend/database-supabase/))
|
||||
- Flux de travail Git et déploiement ([Git et GitHub](../../backend/git-workflow/), [Déployer une application web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Objectifs d'apprentissage
|
||||
|
||||
Après avoir terminé ce projet, vous serez capable de :
|
||||
|
||||
1. Lire un PRD et en extraire une liste de tâches de développement pour une plateforme Agent
|
||||
2. Concevoir des formulaires d'entrée structurés et des formats de sortie structurés
|
||||
3. Implémenter une couche d'orchestration d'agents pour gérer les entrées utilisateur, les appels de modèles et le stockage des résultats
|
||||
4. Construire un cycle métier complet « génération -> sauvegarde -> réutilisation »
|
||||
5. Effectuer des tests de bout en bout et livrer un prototype de produit IA démontrable
|
||||
|
||||
## Présentation du projet
|
||||
|
||||
Le produit que vous allez construire est une plateforme Agent de planification de voyages intelligente :
|
||||
|
||||
| Fonctionnalité | Description |
|
||||
|------|------|
|
||||
| **Planification d'itinéraire** | L'utilisateur saisit le lieu de départ, la destination, les dates, le budget et les préférences ; le système génère un itinéraire journalier |
|
||||
| **Répartition du budget** | Les résultats de l'itinéraire incluent la répartition du budget et des suggestions |
|
||||
| **Gestion de l'historique** | L'utilisateur peut sauvegarder ses plans historiques, les régénérer et les exporter |
|
||||
| **Back-office** | L'administrateur consulte les destinations populaires, les tâches échouées et les retours utilisateurs |
|
||||
|
||||
::: tip Accès au PRD
|
||||
Le document d'exigences de ce projet se trouve sur GitHub : [Voir le PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/fr-fr/stage-2/assignments/travel-planning-agent-platform/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Analyse des besoins', description: 'Lire le PRD, clarifier les pages, l\'orchestration des agents et la structure d\'entrée/sortie' },
|
||||
{ title: 'Construction du squelette', description: 'Générer avec l\'IA le squelette des pages accueil, planification, historique et back-office' },
|
||||
{ title: 'Développement itératif', description: 'Compléter module par module : sortie structurée, statut des tâches, gestion de l\'historique' },
|
||||
{ title: 'Tests et mise en ligne', description: 'Tests de bout en bout, déploiement et préparation de la démonstration' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Partie 1 : Analyse des besoins
|
||||
|
||||
### 1.1 Lire le PRD
|
||||
|
||||
Ouvrez le document PRD et répondez aux questions suivantes :
|
||||
|
||||
- Quels champs le formulaire d'entrée structuré doit-il contenir ?
|
||||
- Quel est le format de sortie attendu pour l'itinéraire généré ?
|
||||
- Comment les tâches sont-elles suivies (statuts, progression) ?
|
||||
- Quelles sont les fonctionnalités du MVP et celles qui peuvent attendre ?
|
||||
|
||||
::: warning
|
||||
Si les questions ci-dessus n'ont pas de réponse claire, ne commencez pas à coder. Une mauvaise compréhension des besoins est la cause la plus fréquente de retour en arrière.
|
||||
:::
|
||||
|
||||
## Partie 2 : Construction du squelette du projet
|
||||
|
||||
### 2.1 Générer les pages frontales
|
||||
|
||||
Prompt de référence :
|
||||
|
||||
```text
|
||||
Veuillez générer, sur la base du PRD actuel, le squelette frontend d'une plateforme de planification de voyages intelligente.
|
||||
|
||||
Exigences :
|
||||
1. Page d'accueil avec formulaire de saisie structuré (départ, destination, dates, budget, préférences)
|
||||
2. Page de planification affichant l'itinéraire généré jour par jour
|
||||
3. Page d'historique des plans sauvegardés
|
||||
4. Page de back-office pour les administrateurs
|
||||
5. Générer d'abord uniquement la structure des pages et des données fictives
|
||||
6. Style moderne et inspirant pour un produit de voyage
|
||||
```
|
||||
|
||||
### 2.2 Vérifier la structure des pages
|
||||
|
||||
- [ ] Le formulaire d'entrée est-il complet et structuré ?
|
||||
- [ ] L'affichage de l'itinéraire est-il clair et organisé par jour ?
|
||||
- [ ] L'historique est-il consultable et réutilisable ?
|
||||
|
||||
## Partie 3 : Développement itératif
|
||||
|
||||
### 3.1 Progresser par module
|
||||
|
||||
1. **Formulaire d'entrée** : Champs structurés avec validation
|
||||
2. **Orchestration de l'agent** : Appel au modèle avec prompt structuré, parsing de la sortie
|
||||
3. **Affichage de l'itinéraire** : Présentation jour par jour avec budget et suggestions
|
||||
4. **Sauvegarde et historique** : Stockage en base de données, listage et réutilisation
|
||||
5. **Back-office** : Statistiques sur les destinations populaires et les échecs
|
||||
|
||||
### 3.2 Structure de sortie de référence
|
||||
|
||||
L'agent doit générer un itinéraire structuré :
|
||||
|
||||
```json
|
||||
{
|
||||
"days": [
|
||||
{
|
||||
"day": 1,
|
||||
"activities": [
|
||||
{"time": "09:00", "activity": "Visite du musée", "cost": 15, "duration": "2h"},
|
||||
{"time": "12:00", "activity": "Déjeuner au marché local", "cost": 20, "duration": "1h"}
|
||||
],
|
||||
"daily_budget": 80,
|
||||
"notes": "Prévoir des chaussures confortables"
|
||||
}
|
||||
],
|
||||
"total_budget": 500,
|
||||
"currency": "EUR"
|
||||
}
|
||||
```
|
||||
|
||||
## Partie 4 : Tests et mise en ligne
|
||||
|
||||
### 4.1 Tests de bout en bout
|
||||
|
||||
- Soumettre un plan -> Consulter l'itinéraire généré -> Sauvegarder -> Retrouver dans l'historique
|
||||
- Régénérer un plan sauvegardé avec des paramètres modifiés
|
||||
|
||||
### 4.2 Déploiement
|
||||
|
||||
- Déployer le frontend sur Vercel / Zeabur
|
||||
- Déployer le backend sur Zeabur / Railway / Render
|
||||
- Utiliser Supabase comme base de données
|
||||
|
||||
## Livrables
|
||||
|
||||
- [ ] Un lien de démonstration en ligne accessible
|
||||
- [ ] Un lien vers le dépôt de code source (avec README)
|
||||
- [ ] Le document PRD
|
||||
- [ ] Des captures d'écran des pages principales
|
||||
- [ ] Une vidéo de démonstration de 60 secondes
|
||||
|
||||
## Critères d'évaluation
|
||||
|
||||
| Dimension | Exigences de base | Exigences avancées |
|
||||
|------|---------|---------|
|
||||
| Planification | L'utilisateur peut soumettre un plan et voir un itinéraire | L'itinéraire est structuré avec budget et suggestions |
|
||||
| Historique | Les plans peuvent être sauvegardés | Les plans sauvegardés peuvent être régénérés et exportés |
|
||||
| Technique | Le backend appelle le modèle et stocke les résultats | Gestion des erreurs, états de chargement et suivi des tâches |
|
||||
| Livraison | Le projet peut être exécuté et déployé | README clair et vidéo de démonstration |
|
||||
|
||||
## Références
|
||||
|
||||
- [Conception UI](../../frontend/ui-design/)
|
||||
- [Bibliothèque de composants moderne](../../frontend/modern-component-library/)
|
||||
- [Des bases de données à Supabase](../../backend/database-supabase/)
|
||||
- [Écriture de code d'interface assistée par IA](../../backend/ai-interface-code/)
|
||||
- [Flux de travail Git et GitHub](../../backend/git-workflow/)
|
||||
- [Comment déployer une application web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,168 @@
|
||||
# Conception et développement d'interfaces backend d'application
|
||||
|
||||
Dans les cours précédents, nous avons appris à utiliser des outils comme Figma pour réaliser des maquettes de conception UI, à utiliser l'IA pour générer rapidement des pages frontend statiques, et à utiliser Supabase pour construire des bases de données et mettre en œuvre une authentification utilisateur préliminaire. Désormais, une question naturelle se pose : après que l'utilisateur a cliqué sur ces boutons dynamiques de la page frontend, comment les données sont-elles silencieusement stockées dans Supabase ? Lorsque nous devons exécuter des logiques métier plus complexes (paiements concurrents, notifications planifiées, traitement de données sensibles), est-il sûr de laisser le frontend se connecter directement à la base de données ?
|
||||
|
||||
Cela nous amène à un maillon crucial de l'architecture de développement web moderne — **l'interface API backend**.
|
||||
|
||||
Plutôt que de taper manuellement des centaines de lignes de routes backend, contrôleurs et logique de validation de paramètres, nous pouvons désormais tirer parti de la puissante capacité de génération de code des grands modèles pour confier le code fastidieux à l'IA. Dans ce cours, nous sortirons du cercle vicieux du « code IA vague et superficiel » et, en nous appuyant sur de véritables scénarios métier, nous vous montrerons comment utiliser des prompts de haute qualité pour guider les grands modèles afin d'écrire des interfaces backend Node.js robustes et conformes aux normes de l'industrie, tout en générant automatiquement la documentation API et les cas de test.
|
||||
|
||||
> 💡 **Prérequis**
|
||||
>
|
||||
> Avant d'étudier cette section, il est recommandé de connaître les sujets suivants :
|
||||
> - [De la base de données à Supabase](../database-supabase/) - Comprendre les concepts de base de données et de modèle de données.
|
||||
> - [Git et GitHub](../git-workflow/) - Se familiariser avec le contrôle de version dans le développement de projets.
|
||||
> - [Qu'est-ce que le terminal/la ligne de commande](/fr-fr/appendix/2-development-tools/command-line-shell) - L'initialisation et le lancement de projets nécessitent des opérations de base en ligne de commande.
|
||||
|
||||
# Ce que vous allez apprendre
|
||||
|
||||
1. **Qu'est-ce qu'une interface API** : Comprendre le pont de communication frontend-backend et les spécifications de conception RESTful.
|
||||
2. **Les grands modèles au service de la construction** : Comment utiliser des prompts structurés pour que l'IA vous aide à monter un projet de base Node.js + Express.
|
||||
3. **Développement de la logique d'interface** : Guider les grands modèles pour générer des interfaces CRUD (créer, lire, mettre à jour, supprimer) avec validation métier rigoureuse et connexion à la base de données Supabase.
|
||||
4. **Documentation API automatisée** : Laisser les grands modèles générer rétroactivement à partir du code la documentation OpenAPI/Swagger, standard de la collaboration inter-équipes.
|
||||
5. **Boucle de test et d'intégration** : Utiliser les grands modèles pour générer des collections de test Postman et des tests unitaires Jest, garantissant la qualité du code.
|
||||
|
||||
---
|
||||
|
||||
# 1. Pourquoi avons-nous besoin d'interfaces API ?
|
||||
|
||||
Dans la compréhension traditionnelle, le frontend est la « partie visible » et la base de données est l'« entrepôt de stockage ». Mais il manque un dispatcher entre les deux. Si vous imaginez l'application comme un restaurant :
|
||||
- **Le frontend (client)** est le menu et la table de commande du restaurant, où les clients parcourent les plats et expriment leurs besoins.
|
||||
- **La base de données (Supabase, etc.)** est l'entrepôt de la cuisine du restaurant, où sont stockés tous les ingrédients et les registres de comptes.
|
||||
- **L'interface API backend** est le serveur du restaurant. Les clients ne peuvent pas se précipiter directement dans la cuisine pour prendre des ingrédients (ce serait chaotique et soulèverait des problèmes de sécurité). Ils doivent communiquer leur « demande de commande » (requête HTTP) au serveur. Celui-ci vérifie (validation des paramètres, authentification des permissions), va chercher le contenu correspondant dans la cuisine, puis rapporte « le plat préparé » (réponse HTTP, généralement au format JSON) au client.
|
||||
|
||||
Grâce aux interfaces API, nous avons réalisé une **séparation frontend-backend** claire : le frontend se concentre uniquement sur le rendu des pages, tandis que le backend se consacre exclusivement à la logique métier, au traitement des données et à la sécurité.
|
||||
|
||||
---
|
||||
|
||||
# 2. Conception de l'architecture du projet et initialisation
|
||||
|
||||
Une structure de projet claire est un prérequis pour que les grands modèles puissent écrire du bon code. Avant de demander à l'IA d'écrire du code, vous devez avoir une idée claire de la structure du projet.
|
||||
|
||||
## 2.1 Structure de projet API courante
|
||||
|
||||
Même en utilisant les grands modèles pour générer du code, vous ne devez jamais tout mettre dans un seul fichier `server.js`. Une architecture backend Node.js maintenable ressemble généralement à ceci :
|
||||
|
||||
```text
|
||||
my-api-project/
|
||||
├── .env # Variables d'environnement sensibles (API Keys, chaîne de connexion base de données)
|
||||
├── server.js # Point d'entrée du projet (démarrage du serveur, enregistrement des middlewares globaux)
|
||||
├── package.json # Fichier de gestion des dépendances
|
||||
├── src/
|
||||
│ ├── routes/ # Couche de routes : définit les chemins URL et les méthodes de requête
|
||||
│ ├── controllers/ # Couche contrôleurs : traite les paramètres de requête métier, appelle les services et retourne les réponses
|
||||
│ ├── services/ # Couche services : encapsule les interactions avec la base de données et la logique métier principale
|
||||
│ └── middlewares/ # Middlewares : authentification, capture globale des erreurs
|
||||
└── docs/ # Répertoire de stockage de la documentation API
|
||||
```
|
||||
|
||||
## 2.2 Initialisation du projet avec l'IA
|
||||
|
||||
Plutôt que de lancer manuellement `npm init` et d'installer les dépendances une par une, il est plus efficace de fournir ces spécifications sous forme de prompt au grand modèle :
|
||||
|
||||
> 🗣️ **Prompt pour le grand modèle (exemple) :**
|
||||
> « Aidez-moi à monter un projet backend Node.js qui doit pouvoir se connecter à une base de données Supabase, avec une structure claire pour faciliter la maintenance future. »
|
||||
|
||||
Après avoir exécuté le code renvoyé par l'IA, vous disposerez d'une application backend avec une ébauche de niveau entreprise sur `localhost:3000`.
|
||||
|
||||
---
|
||||
|
||||
# 3. Pratique centrale : développement d'interface assisté par grand modèle
|
||||
|
||||
C'est la partie la plus importante de ce chapitre. Le code généré par les grands models souffre souvent de « failles logiques » ou de « superficialité », car le contexte fourni par les développeurs est insuffisant. **Les grands modèles ne craignent pas la complexité des besoins, ils craignent l'ambiguïté.**
|
||||
|
||||
Prenons l'exemple de l'interface de création pour la table `menu_items` (table des menus) mentionnée dans le [chapitre sur les bases de données](../database-supabase/), pour voir comment rédiger un prompt de haute qualité.
|
||||
|
||||
## 3.1 Fournir un contexte complet au grand modèle
|
||||
|
||||
Avant de demander à l'IA d'écrire une interface, vous devez toujours fournir la **définition des champs de la base de données (Schema)** et les **contraintes spécifiques**.
|
||||
|
||||
> 🗣️ **Modèle de prompt de haute qualité :**
|
||||
> « Aidez-moi à écrire une interface pour ajouter un élément au menu. Le menu comporte un nom de produit, un prix, une catégorie (burger, accompagnement, boisson) et un statut de disponibilité. Le nom et le prix sont obligatoires, le prix ne peut pas être négatif. Lorsque l'utilisateur saisit des données incorrectes, il faut afficher un message d'erreur. »
|
||||
|
||||
## 3.2 Réviser le code généré par le grand modèle
|
||||
|
||||
Le code généré par le grand modèle ressemble généralement à ceci, avec une séparation claire des responsabilités :
|
||||
|
||||
```javascript
|
||||
// services/menuService.js
|
||||
const { createClient } = require('@supabase/supabase-js');
|
||||
const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY);
|
||||
|
||||
exports.createMenuItem = async (menuData) => {
|
||||
// Appel du SDK Supabase pour insérer les données dans la table
|
||||
const { data, error } = await supabase
|
||||
.from('menu_items')
|
||||
.insert([menuData])
|
||||
.select();
|
||||
|
||||
if (error) throw new Error(`Échec de l'insertion en base de données : ${error.message}`);
|
||||
return data[0];
|
||||
};
|
||||
```
|
||||
|
||||
Vous pouvez constater que le code généré de cette manière est non seulement structurellement raisonnable, mais qu'il prend également en compte l'initialisation de Supabase, la capture d'erreurs et le traitement des exceptions — un monde de différence par rapport au code « spaghetti » obtenu en demandant simplement « écrivez une interface d'ajout ».
|
||||
|
||||
---
|
||||
|
||||
# 4. Libérer les mains : génération automatique de documentation API
|
||||
|
||||
Pour une équipe de développement, une API sans documentation est une boîte noire. Les ingénieurs frontend ne peuvent pas deviner quels paramètres vous attendez, ni prédire la structure de retour. La norme de description d'API la plus répandue dans l'industrie est **OpenAPI (anciennement Swagger)**.
|
||||
|
||||
Auparavant, écrire manuellement des documents Swagger au format YAML ou JSON était extrêmement pénible et source d'erreurs. C'est désormais devenu le domaine d'expertise des grands modèles.
|
||||
|
||||
Vous pouvez simplement sélectionner le code de vos `routes` et `controllers`, puis le fournir au grand modèle :
|
||||
|
||||
> 🗣️ **Prompt pour la génération de documentation :**
|
||||
> « Aidez-moi à générer une documentation d'interface à partir du code ci-dessus. Précisez la signification de chaque paramètre et les données retournées, pour faciliter l'intégration avec les collègues frontend. »
|
||||
|
||||
Dans ce processus, vous pouvez même demander à l'IA de compléter les descriptions des champs (Description) et les données Mock (par exemple `price_cents: 1200` pour 12 euros), réduisant considérablement les coûts de communication.
|
||||
|
||||
---
|
||||
|
||||
# 5. Filet de sécurité : génération de code de test et collection Postman
|
||||
|
||||
Le code est écrit, la documentation est publiée, il reste une dernière étape : vérifier que le code fonctionne réellement.
|
||||
|
||||
## 5.1 Générer une configuration de test Postman / Apifox
|
||||
|
||||
Dans le développement d'interfaces, nous utilisons généralement un outil visuel comme Postman pour simuler les requêtes HTTP envoyées par le frontend. Sans grand modèle, vous devriez saisir manuellement l'URL, ajouter les en-têtes (headers) un par un et assembler le corps de la requête JSON.
|
||||
|
||||
Il vous suffit d'envoyer cette instruction à l'IA :
|
||||
> « Convertissez cette documentation d'interface dans un format importable par Postman, en incluant des exemples de requêtes normales et d'erreurs. »
|
||||
|
||||
Après avoir obtenu le texte JSON, sauvegardez-le sous `menu_api.json` et glissez-le dans Postman : vous disposez instantanément d'un panneau de clics de test prêt à l'emploi.
|
||||
|
||||
## 5.2 Écrire des tests unitaires automatisés
|
||||
|
||||
Si vous visez une qualité d'ingénierie plus rigoureuse, vous pouvez demander au grand modèle de vous aider à écrire des tests unitaires (Unit Tests) avec un framework comme `Jest`, pour tester les limites de la logique métier principale (par exemple, vérifier si la validation au niveau de la base de données fonctionne lorsqu'un prix négatif est transmis).
|
||||
|
||||
---
|
||||
|
||||
# 6. Meilleures pratiques essentielles pour les interfaces backend
|
||||
|
||||
Même avec l'assistance de l'IA, en tant que « gardien » de l'ensemble du système, vous devez connaître et auditer les principes fondamentaux suivants :
|
||||
|
||||
1. **Conventions de nommage RESTful pour les chemins** :
|
||||
- Bon design : `GET /api/users` (obtenir la liste des utilisateurs), `POST /api/users` (créer un utilisateur). Les URL doivent représenter des noms de « ressources ».
|
||||
- Mauvais design : `POST /api/getUser` ou `POST /api/createUser`. Les verbes doivent être exprimés par les méthodes HTTP (GET/POST/PUT/DELETE).
|
||||
2. **Codes d'état HTTP standardisés** :
|
||||
- 200/201 : Requête réussie / Ressource créée avec succès.
|
||||
- 400 : Bad Request, erreur de format des paramètres frontend, champ obligatoire manquant.
|
||||
- 401/403 : Unauthorized / Forbidden, utilisateur non connecté ou sans permission.
|
||||
- 404 : NotFound, ressource inexistante.
|
||||
- 500 : Server Error, erreur de code backend ou base de données hors service. Évitez absolument d'exposer la pile d'erreurs au frontend (risque de sécurité).
|
||||
3. **Ne jamais faire confiance aux entrées utilisateur** : les entrées frontend peuvent être falsifiées. Toutes les validations de paramètres critiques doivent être refaites dans l'interface backend.
|
||||
|
||||
# 7. Résumé
|
||||
|
||||
Au cours de ce chapitre, vous avez opéré un véritable changement de perspective : vous n'êtes plus le « dactylographe » bloqué dans la syntaxe et la ponctuation, mais vous êtes devenu un **designer système et architecte en chef**.
|
||||
|
||||
Vous avez maîtrisé :
|
||||
1. La pensée système centrale des **interfaces API et de la séparation frontend-backend**.
|
||||
2. **Comment fournir du contexte et des concepts de structure en couches** pour améliorer considérablement la qualité du code serveur généré par les grands modèles.
|
||||
3. La transformation astucieuse des tâches fastidieuses de **rédaction de documentation** et de **construction de cas de test** en tâches automatisées où l'IA excelle.
|
||||
4. La combinaison avec les connaissances **Supabase** acquises précédemment, pour compléter le flux de données complet de la requête client à la mise à jour de la base de données sous-jacente.
|
||||
|
||||
::: tip 💡 Prochaine étape
|
||||
Une fois votre flux de données et vos services backend prêts, ils ne fonctionnent encore que sur votre ordinateur local « pour votre propre plaisir ». Dans les prochains chapitres, nous apprendrons comment **déployer (Deploy)** ces services durement construits sur un serveur public, afin que votre produit soit accessible aux utilisateurs du monde entier.
|
||||
:::
|
||||
@@ -0,0 +1,950 @@
|
||||
# De la base de données à Supabase
|
||||
|
||||
Lors du cours précédent, nous avons appris les bases de l'utilisation des outils de conception UI MasterGo et Figma, la récupération de code et la gestion de versions avec GitHub, et le déploiement d'applications et de sites web via Zeabur pour les rendre accessibles au plus grand nombre.
|
||||
|
||||
Pour vous aider à mieux consolider vos connaissances, avant d'aborder les nouveaux contenus de ce cours sur les outils de conception et le déploiement, revoyons ensemble les points clés du cours précédent à travers quelques questions simples :
|
||||
|
||||
1. Qu'est-ce qu'un outil de conception frontend, définition et utilisation de Figma, MasterGo.
|
||||
2. Les méthodes de base pour convertir des maquettes de design en code.
|
||||
3. Qu'est-ce que GitHub, comment configurer SSH, comment créer votre premier dépôt.
|
||||
4. Que signifie le déploiement, comment utiliser Zeabur, comment déployer du code GitHub ou local sur le réseau public pour le rendre accessible.
|
||||
|
||||
Si l'un de ces points reste flou, nous vous recommandons de revoir d'abord les documents et supports du cours précédent. N'hésitez pas à poser vos questions dans le groupe de discussion WeChat.
|
||||
|
||||
Dans ce cours, nous apprendrons comment faire passer une application ou un site web d'un simple état fonctionnel à un produit plus proche d'un véritable service en ligne : non seulement nous utiliserons une base de données pour gérer les différentes évolutions des données de l'application, mais nous mettrons aussi en place un système utilisateur complet (inscription, connexion, permissions) ainsi que d'autres capacités backend essentielles. Nous prendrons Supabase comme plateforme de services backend pour fil conducteur, en l'utilisant d'abord pour implémenter les deux fonctionnalités fondamentales que sont « base de données + système utilisateur », puis en nous appuyant sur les composants fournis par Supabase pour mieux comprendre les modules clés généralement inclus dans les services backend cloud modernes, ainsi que leurs fonctions et logiques spécifiques.
|
||||
|
||||
# Ce que vous allez apprendre
|
||||
|
||||
1. Qu'est-ce qu'une donnée, qu'est-ce qu'une base de données, les bases de données courantes et leurs méthodes d'utilisation
|
||||
2. Qu'est-ce que Supabase, comment utiliser Supabase pour les opérations de base sur une base de données
|
||||
3. Comment utiliser Supabase pour ajouter une gestion basique des utilisateurs à votre application
|
||||
4. Maîtriser les fonctionnalités avancées de Supabase : Realtime, Storage, Edge Functions
|
||||
5. Ajouter la prise en charge de la connexion Google et GitHub à Supabase
|
||||
|
||||
- Une application de base prenant en charge l'inscription/connexion des utilisateurs et le stockage des données dans une base de données en ligne
|
||||
- Un modèle de code backend Supabase réutilisable (base de données + gestion des utilisateurs, etc.) pour vos projets ultérieurs
|
||||
|
||||
# 1. Qu'est-ce qu'une base de données
|
||||
|
||||
## 1.1 Qu'est-ce qu'une donnée
|
||||
|
||||
Dans le monde numérique, les données (Data) sont omniprésentes. En termes simples, les données sont le support de l'information. Les coordonnées de vos amis, un article WeChat, une courte vidéo, le niveau d'un personnage dans un jeu -- tout cela constitue des données. Dans notre application, les données représentent toute information qui doit être enregistrée et gérée, comme les profils utilisateurs, l'historique des commandes, les paramètres du programme, etc.
|
||||
|
||||
En général, les données se présentent sous différentes formes dans un programme. La forme la plus simple est la variable, que nous pouvons utiliser pour stocker des nombres simples :
|
||||
|
||||
```python
|
||||
# Python variable definition examples
|
||||
|
||||
# Integer variable: stores age information
|
||||
age = 30
|
||||
|
||||
# Boolean variable: stores status (whether active)
|
||||
is_active = True # True means active, False means inactive
|
||||
|
||||
# List variable: stores a set of score data
|
||||
scores = [85, 92, 78, 90] # Contains 4 integer elements representing different scores
|
||||
|
||||
# Dictionary variable: stores multiple related information of a user
|
||||
user_info = {
|
||||
"age": 30, # Key "age" corresponds to the value of age
|
||||
"height": 1.80, # Key "height" corresponds to the value of height (unit: meter)
|
||||
"login_count": 156 # Key "login_count" corresponds to the value of login times
|
||||
}
|
||||
```
|
||||
|
||||
Pour les données plus complexes telles que les profils personnels ou l'historique des commandes, nous pouvons utiliser des tableaux plus élaborés pour représenter les données :
|
||||
|
||||
| user_id | name | email |
|
||||
| ------- | ----- | ----------------- |
|
||||
| 1001 | Alice | alice@example.com |
|
||||
| 1002 | Bob | bob@example.com |
|
||||
|
||||
| order_id | user_id | amount | status |
|
||||
| -------- | ------- | ------ | --------- |
|
||||
| 901 | 1001 | 29.99 | completed |
|
||||
| 902 | 1002 | 15.50 | pending |
|
||||
|
||||
Mais pour les données à la structure complexe, présentant des relations hiérarchiques ou des champs variables, nous pouvons utiliser le format JSON pour les décrire -- il s'agit d'un format intermédiaire de données universel sur Internet, compréhensible par presque tous les programmes, ce qui facilite les échanges de données entre systèmes. Par exemple, une commande peut contenir plusieurs articles, chacun ayant son propre nom, sa quantité et son prix. Représenter cela dans un tableau traditionnel serait fastidieux : il faudrait soit diviser les données en plusieurs tables (« table des commandes », « table des articles ») reliées par des champs d'association ; soit utiliser une seule table avec des champs redondants du type « nom article 1, prix article 1, nom article 2... », ce qui est impossible à adapter quand le nombre d'articles varie ; le JSON, quant à lui, permet de représenter directement la hiérarchie « commande - articles - propriétés des articles » de façon intuitive et flexible.
|
||||
|
||||
```json
|
||||
{
|
||||
"order_id": 901,
|
||||
"user_id": 1001,
|
||||
"amount": 29.99,
|
||||
"status": "completed",
|
||||
"items": [
|
||||
{ "sku": "BG-001", "name": "牛肉汉堡", "quantity": 1, "price": 18.00 },
|
||||
{ "sku": "SD-003", "name": "炸薯条", "quantity": 1, "price": 6.99 },
|
||||
{ "sku": "DK-002", "name": "可乐", "quantity": 1, "price": 5.00 }
|
||||
],
|
||||
"shipping_address": {
|
||||
"street": "科技园路123号",
|
||||
"city": "深圳",
|
||||
"zip_code": "518057"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Allons plus loin : si nous considérons une donnée encodée sous forme de vecteur (Vector), il s'agit généralement d'une représentation numérique obtenue en traitant des données non structurées (texte, images ou audio) via un modèle IA (comme un modèle d'Embedding). Sa représentation peut ressembler à ceci :
|
||||
|
||||
`[0.123, -0.456, 0.789, ..., -0.234]` (un tableau de plusieurs centaines, voire milliers de nombres à virgule flottante)
|
||||
|
||||
En résumé, le monde réel regorge de données de formes et d'usages très variés qui méritent une analyse détaillée. Chaque type de données peut nécessiter une base de données spécifique pour son stockage, comme le montre l'illustration ci-dessous -- n'est-ce pas impressionnant ?
|
||||
|
||||
|
||||
|
||||
## 1.2 Pourquoi avons-nous besoin d'une base de données
|
||||
|
||||
Nous avons vu que les données du monde réel ont souvent une structure complexe. **Pour stocker et utiliser efficacement ces données, nous avons besoin d'un programme ou d'un conteneur spécialisé pour les gérer** -- c'est précisément la raison d'être des bases de données (Database). Une base de données est fondamentalement un programme spécialisé dont le rôle principal est d'organiser, de stocker en toute sécurité et de gérer systématiquement les données, tout en prenant en charge des requêtes efficaces.
|
||||
|
||||
Imaginez un instant : sans base de données, que deviendraient les données de votre application ? Lorsque l'utilisateur ferme le navigateur ou quitte l'application, toutes les informations temporairement chargées sont immédiatement perdues ; nous ne pouvons ni sauvegarder durablement l'état d'utilisation (comme les informations de connexion, les paramètres personnalisés), ni partager de données clés entre les utilisateurs (comme le stock de produits, l'historique des commandes). Nous avons absolument besoin d'un dispositif pour stocker toutes nos données !
|
||||
|
||||
Plus souplement encore, le mode de déploiement d'une base de données peut être adapté aux besoins : elle peut être déployée sur un serveur local pour répondre aux exigences de gestion locale des données ; ou déployée dans le cloud, les bases de données cloud prenant en charge la mise à l'échelle élastique (Scale), capable de s'étendre en fonction de la croissance du volume de données et du trafic, et de supporter des données massives et une forte concurrence, garantissant une expérience utilisateur fluide même avec une forte croissance du nombre d'utilisateurs.
|
||||
|
||||
En résumé, grâce à leur stockage persistant efficace, leur gestion fine et leurs capacités de requête rapide, les bases de données résolvent principalement les problèmes suivants :
|
||||
|
||||
- **Stockage persistant des données** : Sans base de données, les données n'existeraient que dans la mémoire de l'application et seraient perdues à sa fermeture. La base de données résout ce problème en stockant les données de manière persistante sur des supports comme les disques durs, assurant leur conservation à long terme et réduisant le risque de perte.
|
||||
- **Requêtes et analyse pratiques des données** : Les bases de données offrent des langages de requête puissants (comme SQL) permettant d'effectuer facilement et efficacement des requêtes, des filtres et des analyses complexes sur des données massives, aidant ainsi les entreprises à prendre de meilleures décisions. Sans base de données, trouver une information spécifique dans une masse de fichiers non organisés serait une tâche extrêmement chronophage et difficile.
|
||||
- **Prise en charge de performances élevées et d'un accès concurrentiel massif** : Grâce à des techniques telles que l'optimisation des index, le cache de requêtes, les pools de connexions et l'architecture distribuée, les bases de données peuvent répondre aux requêtes en quelques millisecondes et supporter des milliers, voire des millions d'utilisateurs simultanés. C'est crucial pour les applications Internet modernes (flash sales e-commerce, flux en temps réel des réseaux sociaux), garantissant la réactivité du système et l'expérience utilisateur. Sans les hautes performances des bases de données, face à un afflux massif de requêtes, le système subirait des retards sévères, voire des pannes.
|
||||
- **Garantie de l'intégrité et de la cohérence des données** : Les bases de données assurent l'exactitude et la cohérence des données grâce à divers mécanismes (contraintes, déclencheurs). Cela signifie que les données de la base doivent respecter des règles prédéfinies : par exemple, l'âge d'un utilisateur doit être un nombre, le numéro de commande doit être unique, empêchant ainsi efficacement la création de données illégales ou invalides.
|
||||
- **Sécurité des données** : Les bases de données fournissent des mécanismes de sécurité robustes, notamment l'authentification des utilisateurs, le contrôle d'accès et le chiffrement des données, pour protéger celles-ci contre les accès, modifications ou destructions non autorisés. Pour faire face aux pannes matérielles, erreurs humaines ou attaques malveillantes, les bases de données proposent également des fonctions de sauvegarde et de restauration. Grâce à des sauvegardes régulières, les données perdues ou endommagées peuvent être restaurées en temps utile, assurant la continuité des activités.
|
||||
|
||||
## 1.3 Bases de données relationnelles et non relationnelles
|
||||
|
||||
Nous avons déjà abordé la valeur essentielle, les modes de déploiement et les avantages d'élasticité des bases de données. Lorsqu'il s'agit de choisir concrètement, la première distinction à opérer est entre les deux grandes catégories : les bases de données relationnelles et les bases de données non relationnelles (NoSQL). Voici une explication simple en quelques phrases :
|
||||
|
||||
Les bases de données relationnelles sont comme des tableaux Excel rigoureusement structurés. Toutes les données doivent avoir un format prédéfini (un Schema défini, par exemple : il faut un nom et un âge, le nom doit être du texte, l'âge un nombre), et les différentes tables sont reliées par des champs d'association (un identifiant servant à connecter les tables, comme un numéro de sécurité sociale). Leur avantage est la précision et la fiabilité des données, idéales pour les virements bancaires, la gestion de stocks et autres scénarios où l'erreur est interdite. L'inconvénient est que la modification de la structure est assez contraignante, et que les performances peuvent être limitées avec des volumes de données massifs.
|
||||
|
||||
Les bases de données non relationnelles (NoSQL) sont comme des dossiers flexibles, capables de stocker des documents, des images ou des paires clé-valeur (une structure de type « mot-définition » similaire à un dictionnaire) dans des formats variés, sans avoir à définir la structure à l'avance. Elles s'adaptent plus facilement aux besoins changeants et aux données à très grande échelle (comme les publications massives des réseaux sociaux), et la mise à l'échelle (ajout de serveurs pour améliorer les performances) est plus simple, mais au prix d'une perte partielle des capacités de requêtes associatives (capacité à consolider des informations de différentes tables) et des garanties de cohérence (assurance que les données restent exactes et non contradictoires), ce qui les rend adaptées aux applications Internet tolérant un certain niveau d'erreur.
|
||||
|
||||
Alors, comment choisir une base de données en pratique ? En résumé, les bases de données relationnelles sont couramment utilisées pour les transactions financières, la gestion de stocks, le traitement de commandes, les systèmes comptables -- des scénarios nécessitant une forte cohérence, des transactions complexes et un équilibre lecture/écriture. Les bases de données non relationnelles conviennent mieux au stockage de contenu de réseaux sociaux, à l'analyse de logs en temps réel, à l'ingestion massive de données IoT, aux systèmes de recommandation avec forte lecture et écriture -- des scénarios à forte concurrence, avec des modes de lecture/écriture déséquilibrés et une structure flexible.
|
||||
|
||||
Mais pour les entreprises, aux premiers stades il n'est pas nécessaire de consacrer beaucoup de temps à réfléchir au choix de la base de données. Les bases de données actuelles sont des produits et services très matures. L'approche la plus directe est de consulter différents fournisseurs de services cloud (des prestataires offrant des ressources et services IT comme des serveurs, du stockage, des bases de données, des logiciels et de la puissance de calcul). Vous pouvez contacter directement les équipes commerciales des fournisseurs cloud pour obtenir une solution de base de données adaptée à vos besoins métier ; et le moyen le plus pratique de construire une application d'entreprise est de privilégier la collaboration avec des fournisseurs spécialisés. (Note : les services d'entreprise sont généralement plus onéreux, il est recommandé de comparer plusieurs offres et, éventuellement, d'acheter des serveurs pour déployer soi-même une base de données open source comme alternative.)
|
||||
|
||||
Vous pouvez également vous référer aux [recommandations de sélection de base de données](https://help.aliyun.com/zh/govcloud/getting-started/select-database-services) d'un fournisseur cloud, qui permettent de choisir différents types de bases de données selon les scénarios, et comparer les spécifications de différents fournisseurs pour trouver la plus adaptée.
|
||||
|
||||
| Type de base de données | Nom | Prix | Scénarios d'utilisation |
|
||||
| ------------ | ---------------- | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Relationnelle | RDS MySQL | Faible | Version de base : apprentissage et petits sites ; version haute disponibilité : scénarios de bases de données de taille moyenne avec une certaine pression métier ; version cluster : métier ne tolérant pas les interruptions, forte pression d'accès |
|
||||
| | RDS SQL Server | Élevé | Version de base : tests et petits sites commerciaux ; version haute disponibilité : sites commerciaux d'entreprise ; version cluster : métier d'entreprise ne tolérant pas les interruptions, forte pression d'accès |
|
||||
| | RDS PostgreSQL | Le plus bas | Version de base : apprentissage et petits sites ; version haute disponibilité : scénarios de bases de données de taille moyenne avec une certaine pression métier ; version cluster : métier ne tolérant pas les interruptions, performances généralement supérieures à MySQL |
|
||||
| | RDS PPAS | Élevé | Usage général : compatible avec les métiers Oracle, pression modérée ; version dédiée : pour les métiers nécessitant un serveur physique dédié, généralement des métiers Oracle à forte concurrence |
|
||||
| | DRDS | Moyen | Version d'entrée : 4 cœurs 8 Go, prix abordable, adapté aux PME en ligne ; version entreprise : 16 cœurs 32 Go, bonne réponse SQL complexe, adaptée aux activités en ligne à très forte concurrence ; version ultime : 32 cœurs 64 Go, meilleure réponse SQL complexe, offre de très grandes capacités |
|
||||
| NoSQL | Redis | Moyen | Redis double actif-standby : généralement utilisé comme base de données persistante pour améliorer la disponibilité ; version cluster Redis : généralement utilisée comme couche de cache pour accélérer les accès applicatifs, résolvant la pression de lecture que les bases de données classiques ne peuvent supporter |
|
||||
| | MongoDB | Moyen | Instance mono-nœud : adaptée au développement, aux tests et au stockage de données non critiques ; instance répliquée : adaptée aux scénarios nécessitant de meilleures performances de lecture, comme les sites de lecture, les systèmes de requête de commandes, ou les pics d'activité temporaires ; instance shardée : cluster basé sur plusieurs réplicas offrant des performances de lecture encore supérieures pour les activités en ligne en temps réel |
|
||||
|
||||
La théorie seule étant parfois difficile à saisir, illustrons avec un scénario concret de « articles de blog » comment les mêmes données sont stockées différemment dans une base de données relationnelle (SQL) et dans différents types de bases de données non relationnelles (NoSQL).
|
||||
|
||||
Supposons que nous ayons une plateforme de blog stockant les informations suivantes :
|
||||
|
||||
- Utilisateurs (Users) : ID utilisateur, nom d'utilisateur, email
|
||||
- Articles (Posts) : ID article, titre, contenu, ID de l'auteur
|
||||
- Commentaires (Comments) : ID commentaire, contenu du commentaire, ID du commentateur, ID de l'article associé
|
||||
- Tags (Tags) : ID tag, nom du tag
|
||||
- Relations articles-tags : plusieurs tags associés à un article, plusieurs articles correspondant à un même tag
|
||||
|
||||
### Exemple de base de données relationnelle (SQL)
|
||||
|
||||
Dans une base de données SQL, nous stockons les différents types de données dans des tables séparées, reliées par des « clés étrangères ». Cette structure est claire, normalisée et réduit la redondance.
|
||||
|
||||
Prenons l'exemple de la « gestion d'articles d'une plateforme de contenu » : au lieu de stocker ensemble « utilisateurs, articles, commentaires, tags », nous les répartissons en 5 tables aux fonctions bien délimitées, chacune avec un « périmètre de responsabilité » clair et une définition de structure stricte (Schema) :
|
||||
|
||||
- Table `users` (stockage des informations utilisateurs)
|
||||
|
||||
| user_id (clé primaire) | username | email |
|
||||
| -------------- | -------- | ----------------- |
|
||||
| 101 | Alice | alice@example.com |
|
||||
| 102 | Bob | bob@example.com |
|
||||
|
||||
- Table `posts` (stockage des articles)
|
||||
|
||||
| post_id (clé primaire) | title | content | author_id (clé étrangère) |
|
||||
| -------------- | --------- | ------------------------------ | ---------------- |
|
||||
| 1 | 初识SQL | 这是关于SQL数据库的一篇文章... | 101 |
|
||||
| 2 | NoSQL入门 | NoSQL提供了灵活的数据模型... | 102 |
|
||||
|
||||
- Table `comments` (stockage des commentaires)
|
||||
|
||||
| comment_id (clé primaire) | body | commenter_id (clé étrangère) | post_id (clé étrangère) |
|
||||
| ----------------- | ---------------- | ------------------- | -------------- |
|
||||
| 1001 | 写得很棒！ | 102 | 1 |
|
||||
| 1002 | 学习了。 | 101 | 2 |
|
||||
| 1003 | 有没有更多例子？ | 101 | 1 |
|
||||
|
||||
- Table `tags` (stockage des tags)
|
||||
|
||||
| tag_id (clé primaire) | tag_name |
|
||||
| ------------- | -------- |
|
||||
| 51 | 数据库 |
|
||||
| 52 | 技术 |
|
||||
| 53 | 入门 |
|
||||
|
||||
- Table `post_tags` (stockage des relations plusieurs-à-plusieurs entre articles et tags)
|
||||
|
||||
| post_id (clé étrangère) | tag_id (clé étrangère) |
|
||||
| -------------- | ------------- |
|
||||
| 1 | 51 |
|
||||
| 1 | 52 |
|
||||
| 2 | 51 |
|
||||
| 2 | 52 |
|
||||
| 2 | 53 |
|
||||
|
||||
Pour interroger les « informations complètes de l'article "初识 SQL" (post_id=1) d'Alice (contenu, auteur, commentaires, tags) », il faut exécuter une requête multi-table (JOIN), en reliant les 5 tables via les clés étrangères et en agrégeant les données. La requête SQL est la suivante :
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
p.title,
|
||||
p.content,
|
||||
u.username AS author,
|
||||
c.body AS comment,
|
||||
t.tag_name AS tag
|
||||
FROM
|
||||
posts p
|
||||
JOIN
|
||||
users u ON p.author_id = u.user_id
|
||||
LEFT JOIN
|
||||
comments c ON p.post_id = c.post_id
|
||||
LEFT JOIN
|
||||
post_tags pt ON p.post_id = pt.post_id
|
||||
LEFT JOIN
|
||||
tags t ON pt.tag_id = t.tag_id
|
||||
WHERE
|
||||
p.post_id = 1;
|
||||
```
|
||||
|
||||
Cette requête traverse 5 tables et agrège toutes les données associées dans un seul résultat. C'est l'avantage central des bases de données relationnelles : grâce à la normalisation et aux opérations de jointure, il est possible d'effectuer toutes sortes de requêtes complexes tout en garantissant la cohérence et une redondance minimale.
|
||||
|
||||
### Exemple de base de données non relationnelle (NoSQL)
|
||||
|
||||
Les bases de données NoSQL (comme MongoDB, Redis) adoptent une philosophie de conception inverse : elles n'insistent pas sur le découpage et la normalisation des données, et regroupent généralement toutes les données associées dans un même agrégat afin de réduire les jointures lors des requêtes et d'améliorer les performances de lecture.
|
||||
|
||||
Dans les bases de données NoSQL, les bases de données orientées documents (Document Database) sont parmi les plus courantes, avec MongoDB comme représentant typique. Elles utilisent le « document » comme unité de stockage de base -- un « document » n'est pas un article au sens habituel, mais une structure de données similaire à JSON (MongoDB utilise le format BSON, qui supporte davantage de types de données) : pas besoin de définir un Schema unifié à l'avance, les champs de chaque document peuvent être ajoutés ou supprimés flexiblement, et les types de champs peuvent être librement ajustés, parfaitement adaptés aux scénarios où les formats de données sont très variables.
|
||||
|
||||
Dans une base de données orientée documents, un article et toutes ses informations associées (commentaires, tags) sont généralement stockés dans un seul document (au format similaire à JSON, avec des champs librement définis, sans Schema prédéfini). La logique centrale est de « stocker l'information complète d'un scénario métier dans un seul document », évitant la concaténation de multiples sources de données lors des requêtes.
|
||||
|
||||
Exemple de document dans la collection `posts` :
|
||||
|
||||
```json
|
||||
{
|
||||
"_id": 1,
|
||||
"title": "初识SQL",
|
||||
"content": "这是关于SQL数据库的一篇文章...",
|
||||
"author": {
|
||||
"user_id": 101,
|
||||
"username": "Alice",
|
||||
"email": "alice@example.com"
|
||||
},
|
||||
"tags": [
|
||||
"数据库",
|
||||
"技术"
|
||||
],
|
||||
"comments": [
|
||||
{
|
||||
"comment_id": 1001,
|
||||
"body": "写得很棒！",
|
||||
"commenter": {
|
||||
"user_id": 102,
|
||||
"username": "Bob"
|
||||
}
|
||||
},
|
||||
{
|
||||
"comment_id": 1003,
|
||||
"body": "有没有更多例子？",
|
||||
"commenter": {
|
||||
"user_id": 101,
|
||||
"username": "Alice"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
L'avantage de cette conception est très intuitive : pour obtenir « les informations complètes du premier article (auteur, commentaires, tags inclus) », il suffit de requêter ce seul document via `_id:1`. La base de données retourne toutes les données en une seule lecture, sans avoir à effectuer les 3-4 jointures de tables comme en SQL -- l'efficacité de lecture est considérablement améliorée.
|
||||
|
||||
Mais cette approche présente aussi un trade-off (compromis) évident : comme les données sont « stockées par agrégation », une redondance de données est inévitable -- par exemple, le `username` de l'auteur « Alice » est intégré dans chaque document d'article qu'elle a écrit. Si un jour « Alice » change son nom d'utilisateur en « Alice_New », il faudrait en théorie parcourir tous les documents d'articles contenant ses informations et mettre à jour le champ `author.username` un par un -- non seulement l'opération est fastidieuse, mais des problèmes de réseau ou de serveur peuvent aussi entraîner l'échec de la mise à jour de certains documents, créant une situation où « le même utilisateur a un nom différent selon les articles ».
|
||||
|
||||
En pratique, cependant, cette redondance est souvent « acceptable » : pour les scénarios de type blogs, médias, fiches produits e-commerce où l'on **lit beaucoup et écrit peu** (les consultations de contenu sont bien plus fréquentes que les modifications de nom d'utilisateur), échanger un peu de redondance contre des « performances de lecture extrêmes » est un choix judicieux. En revanche, pour les scénarios où l'on « écrit beaucoup et lit peu » (comme les modifications fréquentes des informations utilisateurs), il faut pondérer les besoins métier pour déterminer si une base de données orientée documents est pertinente.
|
||||
|
||||
Ce qui précède constitue une introduction simple aux différents types de bases de données. Si vous souhaitez en savoir plus sur les types de bases de données spécifiques, vous pouvez consulter les ressources suivantes pour essayer différentes bases de données.
|
||||
|
||||
Examples of SQL databases :
|
||||
[Db2](https://www.ibm.com/products/db2-database), [MySQL](https://cloud.ibm.com/catalog#highlights), [PostgreSQL](https://www.ibm.com/think/topics/postgresql), [YugabyteDB](https://www.yugabyte.com/), [CockroachDB](https://www.cockroachlabs.com/), [Oracle Database](https://www.ibm.com/products/postgres-enterprise), [Azure SQL Database](https://www.ibm.com/consulting/microsoft)
|
||||
|
||||
Examples of NoSQL databases :
|
||||
[Redis](https://www.ibm.com/think/topics/redis), [CouchDB](https://www.ibm.com/think/topics/couchdb), [MongoDB](https://www.ibm.com/think/topics/mongodb), [Cassandra](https://cloud.ibm.com/catalog#highlights), [Elasticsearch](https://www.ibm.com/think/topics/elasticsearch), [BigTable](https://www.techtarget.com/searchdatamanagement/news/252512583/Google-scales-up-Cloud-Bigtable-NoSQL-database), [Neo4j](https://neo4j.com/users/ibm/), [HBase](https://www.ibm.com/think/topics/hbase)
|
||||
|
||||
# 2. Supabase
|
||||
|
||||
Nous venons de présenter plusieurs types de bases de données courantes et leurs scénarios d'utilisation respectifs. Cependant, dans un projet réel, la base de données n'est généralement qu'un module fondamental de l'infrastructure backend : au-delà du stockage et de la recherche de données, il faut aussi résoudre tout un ensemble de problèmes, notamment **l'inscription et la connexion des utilisateurs, la vérification des permissions, le téléchargement et le stockage de fichiers, les API publiques, voire les tâches planifiées et les notifications en temps réel**. Simplement choisir une bonne base de données ne permet pas à votre application d'« être immédiatement opérationnelle en ligne » -- il reste tout un pan de travail backend fastidieux entre les deux.
|
||||
|
||||
Il faut donc prendre en compte un contexte plus large : **les services backend**. Une application complète est généralement composée d'un « frontend + backend » : le frontend gère l'affichage des pages et les interactions utilisateur, tandis que le backend se charge du stockage des données, de la connexion des utilisateurs, du traitement de la logique métier, etc. Autrefois, les développeurs devaient installer leurs propres serveurs, configurer les bases de données, concevoir et implémenter les API, et gérer manuellement les permissions, les stratégies de sécurité, l'évolutivité et la supervision -- un processus à la fois répétitif et chronophage. Pour résoudre ces tâches répétitives, l'industrie a vu apparaître le **BaaS (Backend as a Service)** : une plateforme cloud regroupant les fonctionnalités backend courantes -- base de données, authentification des utilisateurs, stockage de fichiers, capacités temps réel -- que les développeurs peuvent appeler directement via SDK/API, sans avoir à construire et maintenir l'infrastructure depuis zéro.
|
||||
|
||||
Dans ce contexte, [Supabase](https://supabase.com/) peut être considéré comme un représentant de nouvelle génération du BaaS : il prend PostgreSQL comme base de données centrale et y intègre un ensemble complet de capacités backend -- Auth, Storage, Realtime, Edge Functions, Vector -- offrant aux développeurs une « plateforme backend tout-en-un centrée sur Postgres ». Abordons maintenant ce sujet en passant de « choisir uniquement une base de données » à « choisir une plateforme complète de développement backend », et voyons concrètement ce que Supabase permet d'éviter et comment il réduit considérablement la distance entre un prototype et un produit utilisable.
|
||||
|
||||
## 2.1 Guide pas à pas
|
||||
|
||||
Après avoir bien compris le positionnement global de Supabase, nous allons suivre le parcours de la console Supabase pour détailler les capacités centrales qu'il offre et les responsabilités de chacune. Nous présenterons en détail chaque option de Supabase pour vous aider à prendre en main rapidement ses opérations de base.
|
||||
|
||||
|
||||
|
||||
Après vous être connecté sur le site officiel de Supabase, cliquez sur « New project » sur la page d'accueil de la console pour lancer la création ;
|
||||
|
||||
Saisissez les informations principales requises : Project Name, mot de passe de la base de données, et choisissez comme région celle qui est la plus proche des utilisateurs cibles de votre application.
|
||||
|
||||
|
||||
|
||||
Une fois la création réussie, la barre latérale gauche de la console affichera tous les modules fonctionnels clés (Table Editor, SQL Editor, Database, Authentication, etc.). Les opérations suivantes s'articuleront autour de ces modules.
|
||||
|
||||
|
||||
|
||||
### Éditeur de tables (Table Editor)
|
||||
|
||||
Table Editor est l'éditeur visuel de tables de données de Supabase. Il vous permet de visualiser et modifier directement les données de la base de données comme sur Excel, sans écrire de SQL -- il suffit d'interagir à la souris pour modifier le contenu des données.
|
||||
|
||||
|
||||
|
||||
Un point notable est le Schema. Le Schema peut être compris comme un « conteneur de ressources » au sein de la base de données, utilisé pour organiser en groupes les tables, vues, fonctions, index et autres ressources. Ses deux rôles principaux sont : éviter les conflits de nommage (des tables de même nom peuvent exister dans différents Schémas) et mettre en place une isolation de permissions (par exemple n'autoriser que certains utilisateurs à accéder aux tables d'un Schema donné).
|
||||
|
||||
Cliquez sur la liste déroulante Schema en haut de l'éditeur pour basculer entre les différents conteneurs. En développement quotidien, vous n'avez généralement besoin de vous concentrer que sur deux catégories :
|
||||
|
||||
- `public` : le conteneur de ressources publiques par défaut. Les tables métier créées par les développeurs (comme « table des articles », « table des commentaires ») y sont stockées ;
|
||||
- `auth` : le conteneur dédié à l'authentification des utilisateurs. Sa table `users` stocke automatiquement les informations de tous les utilisateurs inscrits (ID utilisateur, email, heure de connexion, etc.). Il n'est pas recommandé de modifier manuellement les tables par défaut de ce Schema pour ne pas affecter les fonctionnalités d'authentification ;
|
||||
|
||||
|
||||
|
||||
### Éditeur SQL (SQL Editor)
|
||||
|
||||
Le SQL Editor est l'exécuteur d'instructions SQL de Supabase, vous permettant de manipuler directement la base de données par du code. Vous pouvez demander à un grand modèle de générer des instructions SQL, les saisir à droite puis cliquer sur RUN pour créer ou modifier des tables, et visualiser directement les données filtrées dans la section Results.
|
||||
|
||||
|
||||
|
||||
Après avoir exécuté RUN, vous retrouverez les nouvelles tables créées dans le Schema public du Table Editor ; les requêtes exécutées sont sauvegardées dans la section PRIVATE à gauche, et vous pouvez même cliquer sur l'icône cœur sous la requête pour l'ajouter en favoris.
|
||||
|
||||
### Centre de gestion de la base de données (Database)
|
||||
|
||||
Database est le centre de gestion de la base de données de Supabase, permettant de visualiser et gérer toutes les tables de données, et de comprendre les relations entre les tables grâce à des lignes de connexion (contraintes de clé étrangère, représentant les relations de référence entre les données).
|
||||
|
||||
|
||||
|
||||
Si vous souhaitez créer manuellement une nouvelle table, vous pouvez le faire directement dans la section tables. Nous détaillerons cette opération dans les tutoriels suivants.
|
||||
|
||||
|
||||
|
||||
### Authentification (Authentication)
|
||||
|
||||
Authentication gère l'inscription, la connexion et les permissions des utilisateurs. Les données du système de gestion des utilisateurs par défaut y sont stockées. Il offre des fonctionnalités prêtes à l'emploi : inscription, connexion, réinitialisation du mot de passe, vérification par email, et prend en charge la connexion OAuth tiers (WeChat, GitHub, Google, etc.). Toutes les données utilisateurs sont automatiquement synchronisées dans la table `auth.users` de la base de données.
|
||||
|
||||
|
||||
|
||||
Vous trouverez dans l'option Provider les différentes entrées de connexion prises en charge par Supabase. Par défaut, l'email est utilisé ; si vous souhaitez utiliser GitHub ou Google pour la connexion, une configuration supplémentaire est nécessaire, que nous détaillerons dans les cours suivants.
|
||||
|
||||
|
||||
|
||||
La section Sign In / Providers inclut également le contrôle du comportement d'inscription par email. Si vous ne souhaitez pas que chaque inscription par email nécessite une confirmation préalable de l'utilisateur, vous pouvez désactiver l'obligation de confirmer l'email.
|
||||
|
||||
|
||||
|
||||
Si vous souhaitez utiliser un autre fournisseur de services d'authentification que Supabase, vous pouvez cliquer sur Third Party Auth -- par exemple, utiliser Clerk comme fournisseur tiers.
|
||||
|
||||
|
||||
|
||||
Si vous craignez un afflux d'utilisateurs inscrits à court terme, vous pouvez activer les stratégies de limitation de débit dans Rate Limits :
|
||||
|
||||
|
||||
|
||||
### Stockage (Storage)
|
||||
|
||||
Storage est le système de stockage de Supabase, compatible avec le concept S3 d'Amazon Cloud. Il permet de stocker tout type de fichiers (images, vidéos, documents, audio, etc.) et offre une gestion des permissions d'accès (public ou privé) ainsi que des liens de téléchargement (permanents ou temporaires). Vous pouvez facilement gérer les fichiers des utilisateurs dans votre application et intégrer le système d'authentification de Supabase pour un contrôle d'accès fin.
|
||||
|
||||
|
||||
|
||||
Nous présenterons l'utilisation concrète de Storage dans le projet avancé de ce cours.
|
||||
|
||||
|
||||
|
||||
Si vous souhaitez utiliser les protocoles S3 pour vos opérations, vous pouvez utiliser directement la configuration correspondante :
|
||||
|
||||
|
||||
|
||||
> Amazon Cloud (Amazon Web Services, ou AWS) est la plateforme de cloud computing d'Amazon (comme une immense salle serveur en ligne où vous pouvez louer à la demande des ressources de calcul et de stockage). S3 (Simple Storage Service) est le service d'AWS dédié au stockage de fichiers (similaire à un disque dur en ligne illimité, pour stocker images, vidéos, sauvegardes et autres fichiers). C'est aujourd'hui le service de stockage d'objets le plus populaire, devenu un standard de facto dans l'industrie.
|
||||
>
|
||||
> **Pourquoi proposer une API compatible S3 ?** : S3 existe depuis près de 20 ans. Il existe de nombreux outils, SDK et documentations prêts à l'emploi. La compatibilité S3 signifie que vous pouvez utiliser directement ces ressources sans avoir à tout recréer, ce qui accélère la mise en production.
|
||||
|
||||
### Edge Functions
|
||||
|
||||
Si vous ne souhaitez pas déployer de backend mais avez besoin d'opérations sur la base de données et de fonctions, vous pouvez utiliser les Edge Functions pour bénéficier de capacités backend sans serveur. Ce sont des fonctions côté serveur distribuées globalement fournies par Supabase. En termes simples, elles vous permettent d'écrire et déployer du code backend dans le cloud sans avoir à acheter ni gérer vos propres serveurs. Ces fonctions sont déployées sur les nœuds de périphérie du réseau mondial et s'exécutent automatiquement au plus près de vos utilisateurs, réduisant ainsi considérablement la latence réseau pour une vitesse de réponse optimale. Vous pouvez créer, éditer et déployer directement depuis le tableau de bord Supabase -- le flux de développement est très pratique.
|
||||
|
||||
|
||||
|
||||
Un usage clé des Edge Functions est de servir d'intercouche sécurisée pour protéger vos informations sensibles et vos clés d'authentification. Appeler directement des services tiers (comme OpenAI, Stripe) depuis le code frontend expose votre clé API, avec tous les risques de sécurité que cela implique. Grâce aux Edge Functions, votre application frontend ne communique qu'avec votre fonction Supabase, et tous les secrets sont conservés uniquement dans Supabase.
|
||||
|
||||
|
||||
|
||||
Les Edge Functions utilisent les clés exposées dans les secrets comme variables d'environnement, chargées via `Deno.env.get`, pour réaliser les appels aux services tiers. Ainsi, les clés sensibles ne sont jamais exposées côté client (votre navigateur), éliminant définitivement le risque de vol.
|
||||
|
||||
|
||||
|
||||
Lors d'une requête à une Edge Function Supabase, la clé Supabase correspondante doit être incluse dans l'en-tête de la requête. Voici un exemple minimal :
|
||||
|
||||
```javascript
|
||||
// Configuration principale (remplacez par vos informations réelles)
|
||||
const projectId = "Votre ID de projet Supabase";
|
||||
const functionName = "Nom de l'Edge Function cible";
|
||||
const supabaseKey = "Clé anon_key Supabase";
|
||||
|
||||
// Appel de la fonction
|
||||
async function callEdgeFunction() {
|
||||
const url = `https://${projectId}.supabase.co/functions/v1/${functionName}`;
|
||||
|
||||
try {
|
||||
const response = await fetch(url, {
|
||||
method: "POST",
|
||||
headers: {
|
||||
"Content-Type": "application/json",
|
||||
"Authorization": `Bearer ${supabaseKey}` // Clé : authentification via la clé
|
||||
},
|
||||
body: JSON.stringify({ order_id: "123", action: "refund" }) // Données de requête personnalisées
|
||||
});
|
||||
|
||||
const result = await response.json();
|
||||
console.log("Appel réussi :", result);
|
||||
} catch (error) {
|
||||
console.error("Échec de l'appel :", error.message);
|
||||
}
|
||||
}
|
||||
|
||||
// Exécuter l'appel
|
||||
callEdgeFunction();
|
||||
```
|
||||
|
||||
En outre, les Edge Functions s'intègrent parfaitement au système d'authentification des utilisateurs de Supabase. Lorsqu'un utilisateur connecté appelle une fonction, ses informations d'identité sont transmises à la fonction. Vous pouvez ainsi identifier facilement l'utilisateur courant dans la fonction et appliquer des contrôles de permissions en fonction de son identité. Plus important encore, lors des opérations sur la base de données, les fonctions respectent automatiquement les politiques de sécurité au niveau des lignes (Row Level Security) que vous avez définies, garantissant que les utilisateurs ne peuvent accéder et modifier que les données qu'ils sont autorisés à manipuler -- simplifiant la création d'applications multi-utilisateurs sécurisées.
|
||||
|
||||
Les cas d'usage des Edge Functions sont très variés et couvrent toutes sortes de tâches backend. Elles sont idéales pour écouter les événements Webhook de services tiers (paiement réussi, commit de code, etc.) et exécuter automatiquement la logique de traitement correspondante. Vous pouvez aussi les utiliser pour envoyer des notifications par email, générer des rapports PDF, créer des interfaces API personnalisées encapsulant une logique métier complexe, ou exécuter toute tâche de calcul que vous souhaitez réaliser côté serveur -- étendant considérablement les capacités de votre application.
|
||||
|
||||
Prenons un exemple concret : l'outil d'authentification Clerk. Clerk ne gère que les opérations liées à l'authentification (connexion, inscription, mise à jour des informations), sans gérer directement votre base de données métier. Pour synchroniser ces informations d'authentification avec votre base de données métier, il faut passer par des événements Webhook qui déclenchent des Edge Functions. Celles-ci écoutent les signaux Webhook de Clerk et exécutent automatiquement la logique de synchronisation, alignant en temps réel les informations utilisateur dans la base Supabase avec l'état de connexion Clerk -- le tout sans déployer un backend indépendant.
|
||||
|
||||
### Moteur de synchronisation de données en temps réel (Realtime)
|
||||
|
||||
Realtime est le moteur de synchronisation de données en temps réel de Supabase, qui permet à votre application de recevoir instantanément les notifications de modifications de la base de données sans avoir à interroger l'API de manière répétée. Lorsqu'une opération `INSERT`, `UPDATE` ou `DELETE` est effectuée sur les données, Realtime pousse ces modifications en temps réel à tous les clients connectés via WebSocket. C'est essentiel pour les applications nécessitant des interactions en temps réel.
|
||||
|
||||
Realtime comprend principalement trois fonctionnalités clés, couvrant la plupart des scénarios temps réel :
|
||||
|
||||
1. **Postgres Changes** : écoute directement les modifications des tables de la base de données. Vous pouvez vous abonner avec précision à des tables spécifiques, à des événements spécifiques (insertion, suppression, modification), voire filtrer les notifications selon des critères, le tout parfaitement intégré aux politiques de sécurité au niveau des lignes (Row Level Security) pour garantir que les utilisateurs ne reçoivent que les modifications auxquelles ils ont accès.
|
||||
2. **Broadcast** : permet aux clients d'envoyer des messages temporaires à faible latence via des canaux (Channel). Idéal pour les salons de discussion, le suivi de curseurs en temps réel, la synchronisation d'état dans les jeux en ligne, etc.
|
||||
3. **Presence** : utilisé pour suivre et synchroniser l'état des utilisateurs en ligne. Vous pouvez facilement implémenter des fonctionnalités comme « qui est en ligne » ou « X personnes consultent actuellement cette page », parfaitement adapté aux applications collaboratives.
|
||||
|
||||
Nous détaillerons cette partie dans les projets avancés.
|
||||
|
||||
### Paramètres du projet (Project Settings)
|
||||
|
||||
Project Settings est la section de configuration avancée de votre projet Supabase, où vous pouvez gérer finement les ressources de calcul et configurer les paramètres basiques des différentes fonctionnalités.
|
||||
|
||||
|
||||
|
||||
Au stade débutant, concentrons-nous sur deux sections clés. La première est Data API, où vous obtenez le « Supabase URL » clé -- un point de terminaison RESTful au format `https://xxx.supabase.co`, qui est l'« adresse d'entrée » pour toutes les opérations de création, lecture, mise à jour et suppression de données. Le frontend ou le serveur doit utiliser cette URL pour initialiser le client Supabase et établir la connexion à la base de données.
|
||||
|
||||
|
||||
|
||||
L'autre point important est API Keys. Sélectionnez l'onglet « Legacy anon, service_role API keys ». La clé anon public est un identifiant essentiel pour les scénarios frontend, dont les permissions sont strictement limitées par les politiques RLS, n'autorisant l'accès qu'aux données que l'utilisateur est autorisé à consulter. La clé service_role est une « clé de haute permissions côté serveur », capable de contourner la sécurité au niveau des lignes pour exécuter des opérations de données en lot ou des configurations système. Elle ne doit jamais être partagée publiquement ; en cas de fuite, générez immédiatement une nouvelle clé et mettez à jour la configuration côté serveur.
|
||||
|
||||
|
||||
|
||||
Les autres paramètres n'ont pas besoin d'être approfondis à ce stade. Vous pourrez les explorer au fur et à mesure de vos besoins avancés.
|
||||
|
||||
## 2.1 Créer votre première table de données SQL
|
||||
|
||||
Voici pour la présentation de l'interface Supabase. Passons maintenant aux opérations sur la base de données centrale de Supabase.
|
||||
|
||||
Pour créer une table de données dans Supabase, il existe principalement deux méthodes courantes, au choix selon vos besoins :
|
||||
|
||||
1. (Recommandé) Utiliser un grand modèle de langage pour générer des instructions SQL adaptées à Supabase, puis les coller et exécuter directement dans le **SQL Editor** (l'exécuteur SQL présenté précédemment) -- rapide et efficace. Nous détaillerons ce processus dans la section suivante.
|
||||
2. Créer via des opérations visuelles : dans la barre latérale de gauche, trouvez le module Database, cliquez dessus, sélectionnez Tables dans la barre latérale, puis cliquez sur le bouton New table à droite pour créer une table via l'interface graphique.
|
||||
|
||||
|
||||
|
||||
Il est à noter que le nom de la table et les types de données peuvent être spécifiés dans la section Columns située en dessous.
|
||||
|
||||
|
||||
|
||||
Pour les bases de données relationnelles, un aspect important est les relations entre les tables. Vous trouverez ci-dessous la section `Foreign keys`, où vous pouvez créer les relations correspondantes :
|
||||
|
||||
|
||||
|
||||
Un `Foreign key` exprime la relation d'association entre les tables : un ou plusieurs champs de la table actuelle (table enfant) dont les valeurs référencent la clé primaire d'une autre table (table parent).
|
||||
|
||||
Par exemple, lors de la création d'une `table étudiants`, nous pouvons définir la clé étrangère ainsi : (la colonne `Numéro de classe` est une clé étrangère qui référence la colonne `Numéro de classe` de la `table classes`.)
|
||||
|
||||
```sql
|
||||
CREATE TABLE 学生表 (
|
||||
学生学号 INT PRIMARY KEY,
|
||||
学生姓名 VARCHAR(50),
|
||||
所属班级编号 INT,
|
||||
FOREIGN KEY (所属班级编号) REFERENCES 班级表(班级编号)
|
||||
);
|
||||
```
|
||||
|
||||
Pour être plus concret, observons visuellement la structure des tables correspondantes :
|
||||
|
||||
Table des classes :
|
||||
Cette table enregistre les informations de toutes les classes, chacune ayant un numéro de classe unique. Le numéro de classe est la clé primaire (Primary Key) de cette table, l'identifiant unique de chaque classe.
|
||||
|
||||
| 班级编号 | 班级名称 |
|
||||
| -------- | ---------- |
|
||||
| 101 | 一年级一班 |
|
||||
| 102 | 一年级二班 |
|
||||
|
||||
Table des étudiants :
|
||||
Cette table enregistre les informations de tous les étudiants. Chaque étudiant appartient à une classe spécifique, n'est-ce pas ? Comment savoir quel étudiant est dans quelle classe ?
|
||||
|
||||
Nous pouvons ajouter une colonne dans la table des étudiants, appelée `Numéro de classe`.
|
||||
|
||||
| 学生学号 | 学生姓名 | 所属班级编号 |
|
||||
| -------- | -------- | ------------ |
|
||||
| 2024001 | 张三 | 101 |
|
||||
| 2024002 | 李四 | 102 |
|
||||
| 2024003 | 王五 | 101 |
|
||||
|
||||
Dans cet exemple, la colonne `Numéro de classe` de la table des étudiants est la clé étrangère (Foreign Key).
|
||||
|
||||
Dans Supabase, après avoir cliqué sur « Add Foreign Key », vous pouvez directement sélectionner la table et la colonne associées.
|
||||
|
||||
|
||||
|
||||
## 2.3 Présentation du SQL Editor et opérations de base sur la base de données
|
||||
|
||||
Nous allons maintenant exécuter pas à pas une série de scripts SQL pour nous familiariser avec les opérations courantes de CRUD (création, lecture, mise à jour, suppression) en SQL. Vous pouvez copier le code de chaque étape dans le SQL Editor, l'exécuter et observer les résultats.
|
||||
|
||||
Vous trouverez tous les fichiers SQL de test dans ce répertoire :
|
||||
|
||||
https://github.com/THU-SIGS-AIID/Project5-Supabase-Demos/tree/main/apps/sql-examples
|
||||
|
||||
### **2.3.1 `CREATE` -- Créer la structure d'une table**
|
||||
|
||||
L'instruction `CREATE TABLE` sert à définir le schéma (Schema) d'une nouvelle table, incluant ses colonnes (Columns), les types de données correspondants (Data Types) et les éventuelles contraintes (Constraints). En termes simples, cela crée une table de données.
|
||||
|
||||
```sql
|
||||
-- Step 1: Create the 'orders' table
|
||||
-- This file is fully independent and creates a sample table for later steps.
|
||||
CREATE TABLE IF NOT EXISTS orders (
|
||||
id serial PRIMARY KEY,
|
||||
user_id int NOT NULL, -- User ID
|
||||
status text NOT NULL, -- Order status (e.g. paid, pending)
|
||||
amount numeric(10, 2) NOT NULL, -- Order total amount
|
||||
details jsonb, -- Item and extra details as JSON
|
||||
placed_at timestamptz DEFAULT now(), -- Order creation time
|
||||
is_paid boolean DEFAULT false -- Paid flag
|
||||
);
|
||||
|
||||
-- Expected Output:
|
||||
-- Orders table created if it did not exist.
|
||||
-- No data inserted. (Querying returns zero rows for now.)
|
||||
-- If table already exists, no error occurs.
|
||||
```
|
||||
|
||||
Après une exécution réussie, le système indiquera que le script est terminé. Vous pourrez voir la table nouvellement créée dans le Table Editor :
|
||||
|
||||
|
||||
|
||||
### **2.3.2 `INSERT` -- Insérer des données initiales**
|
||||
|
||||
Une fois la structure de la table créée, l'étape suivante consiste à utiliser l'instruction `INSERT INTO` pour ajouter des lignes de données à la table.
|
||||
|
||||
```sql
|
||||
-- Step 2: Insert initial rows into the orders table
|
||||
-- Provides realistic, varied data for demo/testing. All values are self-contained.
|
||||
INSERT INTO orders (user_id, status, amount, details, placed_at, is_paid) VALUES
|
||||
(2001, 'pending', 23.50, '{"items":[{"sku":"BGR001","name":"Beef Burger","qty":1,"price":12.00}]}', now() - interval '2 days', false),
|
||||
(2002, 'paid', 50.00, '{"items":[{"sku":"BGR002","name":"Chicken Burger","qty":2,"price":10.00},{"sku":"DRK001","name":"Lemonade","qty":2,"price":5.00}]}', now() - interval '1 day', true),
|
||||
(2003, 'cancelled', 15.00, '{"items":[{"sku":"FRY001","name":"French Fries","qty":3,"price":5.00}], "reason":"Not available"}', now() - interval '45 days', false),
|
||||
(2004, 'paid', 22.98, '{"items":[{"sku":"BGR003","name":"Veggie Burger","qty":2,"price":9.99}], "promo":"SUMMER22"}', now() - interval '10 days', true),
|
||||
(2005, 'pending', 18.75, '{"items":[{"sku":"SAL001","name":"Salad","qty":1,"price":6.75},{"sku":"BGR001","name":"Beef Burger","qty":1,"price":12.00}]}', now() - interval '7 hours', false),
|
||||
(2006, 'paid', 8.00, '{"items":[{"sku":"DRK002","name":"Cola","qty":2,"price":4.00}]}', now() - interval '3 hours', true),
|
||||
(2007, 'refunded', 14.50, '{"items":[{"sku":"BGR003","name":"Veggie Burger","qty":1,"price":9.99},{"sku":"FRY001","name":"French Fries","qty":1,"price":4.51}], "refund_reason":"Late delivery"}', now() - interval '15 days', false),
|
||||
(2008, 'paid', 26.99, '{"items":[{"sku":"BGR002","name":"Chicken Burger","qty":2,"price":10.00},{"sku":"DRK001","name":"Lemonade","qty":1,"price":6.99}]}', now() - interval '12 days', true),
|
||||
(2009, 'pending', 9.99, '{"items":[{"sku":"BGR003","name":"Veggie Burger","qty":1,"price":9.99}]}', now() - interval '30 minutes', false),
|
||||
(2010, 'paid', 19.89, '{"items":[{"sku":"BGR001","name":"Beef Burger","qty":1,"price":12.00},{"sku":"DRK002","name":"Cola","qty":2,"price":3.95}]}', now() - interval '5 days', true),
|
||||
(2011, 'cancelled', 0.00, '{"items":[], "reason":"User cancelled"}', now() - interval '2 days', false);
|
||||
|
||||
-- Expected Output:
|
||||
-- After running this script, SELECT * FROM orders will show about 11 rows with varied user_id, status, amount, details (JSON), placed_at, and is_paid fields.
|
||||
-- For example:
|
||||
-- | id | user_id | status | amount | is_paid | placed_at |
|
||||
-- |----|---------|-----------|--------|---------|---------------------|
|
||||
-- | 1 | 2001 | pending | 23.50 | false | 2025-10-28 13:40:00Z|
|
||||
-- | 2 | 2002 | paid | 50.00 | true | ... |
|
||||
-- |... | ... | ... | ... | ... | ... |
|
||||
```
|
||||
|
||||
Après exécution, les données initiales ont été insérées dans la table. Vous pouvez accéder à l'interface du Table Editor, actualiser et voir les résultats, ou ouvrir une nouvelle fenêtre dans le SQL Editor et exécuter la requête `SELECT * FROM orders;` pour visualiser les résultats :
|
||||
|
||||
|
||||
|
||||
### **2.3.3 `SELECT` -- Lire et interroger les données**
|
||||
|
||||
L'instruction `SELECT` permet de récupérer des données depuis une table. En combinant différentes clauses, il est possible de filtrer, trier et formater les données avec précision. Voici quelques exemples à exécuter pas à pas :
|
||||
|
||||
```sql
|
||||
-- Step 3: SELECT query examples for the orders table
|
||||
|
||||
-- Example 1: Select all fields for all orders
|
||||
SELECT * FROM orders;
|
||||
-- Expected Output: Returns all rows and fields. Columns: id, user_id, status, amount, details, placed_at, is_paid.
|
||||
|
||||
-- Example 2: Select only pending orders
|
||||
SELECT id, user_id, amount FROM orders WHERE status = 'pending';
|
||||
-- Expected Output: All rows with status 'pending'; columns: id, user_id, amount.
|
||||
|
||||
-- Example 3: Select specific fields and filter by payment status
|
||||
SELECT id, status, is_paid, amount FROM orders WHERE is_paid = true;
|
||||
-- Expected Output: All rows where is_paid is true; columns: id, status, is_paid, amount.
|
||||
|
||||
-- Example 4: Extract all item names from the details (JSON) for each order
|
||||
SELECT id, details -> 'items' AS item_list FROM orders;
|
||||
-- Expected Output: Each row shows id and an array from JSON with item details.
|
||||
```
|
||||
|
||||
- **Exemple 1 :** Retourne toutes les lignes et colonnes de la table `orders`, similaire à la sortie de l'étape 2.
|
||||
- **Exemple 2 :** Retourne uniquement les commandes au statut 'pending', avec les colonnes spécifiées :
|
||||
|
||||
|
||||
|
||||
- **Exemple 3 :** Retourne uniquement les commandes payées, avec les colonnes spécifiées :
|
||||
|
||||
| id | status | is_paid | amount |
|
||||
| --- | ------ | ------- | ------ |
|
||||
| 2 | paid | true | 50.00 |
|
||||
| 4 | paid | true | 22.98 |
|
||||
| 6 | paid | true | 8.00 |
|
||||
| 8 | paid | true | 26.99 |
|
||||
| 10 | paid | true | 19.89 |
|
||||
|
||||
- **Exemple 4 :** Retourne l'`id` de chaque commande et le tableau `items` extrait du champ `details` :
|
||||
|
||||
| id | item_list |
|
||||
| --- | -------------------------------------------------------------------------------------------------------------------- |
|
||||
| 1 | `[{"qty":1,"sku":"BGR001","name":"Beef Burger","price":12}]` |
|
||||
| 2 | `[{"qty":2,"sku":"BGR002","name":"Chicken Burger","price":10},{"qty":2,"sku":"DRK001","name":"Lemonade","price":5}]` |
|
||||
| 3 | `[{"qty":3,"sku":"FRY001","name":"French Fries","price":5}]` |
|
||||
| ... | ... |
|
||||
|
||||
### **2.3.4 `INSERT` -- Insérer un enregistrement unique**
|
||||
|
||||
Dans la section 2.3.2, nous avons démontré l'insertion de données en lot au moment de l'initialisation. Voyons maintenant comment insérer une seule donnée.
|
||||
|
||||
```sql
|
||||
-- Step 4: INSERT a new order (single row)
|
||||
INSERT INTO orders (user_id, status, amount, details, is_paid)
|
||||
VALUES (
|
||||
2012, 'paid', 9.99,
|
||||
'{"items":[{"sku":"BGR002","name":"AIID Burger","qty":100,"price":1000}]}',
|
||||
true
|
||||
);
|
||||
```
|
||||
|
||||
En interrogeant ensuite avec `SELECT * FROM orders;`, nous pouvons constater que la table orders est passée de 11 à 12 enregistrements.
|
||||
|
||||
### **2.3.5 `UPDATE` -- Modifier des données existantes**
|
||||
|
||||
L'instruction `UPDATE` permet de modifier les enregistrements existants dans une table.
|
||||
|
||||
```sql
|
||||
-- Step 5: UPDATE example
|
||||
UPDATE orders SET status = 'paid', is_paid = true WHERE id = 1;
|
||||
```
|
||||
|
||||
### **2.3.6 `DELETE` -- Supprimer des données**
|
||||
|
||||
L'instruction `DELETE` permet de supprimer des enregistrements d'une table.
|
||||
|
||||
```sql
|
||||
-- Step 6: DELETE example
|
||||
DELETE FROM orders WHERE placed_at < now() - interval '2 days';
|
||||
```
|
||||
|
||||
Avant l'exécution, vous pouvez d'abord exécuter `SELECT id, status, placed_at FROM orders WHERE placed_at < now() - interval '2 days';` pour visualiser les données qui seront supprimées. Après avoir exécuté la commande `DELETE`, réexécutez la même requête -- le résultat sera vide, confirmant que ces lignes ont été supprimées.
|
||||
|
||||
## 2.4 Sécurité au niveau des lignes (RLS)
|
||||
|
||||
Après avoir appris les opérations de base sur les bases de données, nous devons approfondir un concept central de sécurité des données : RLS (Row Level Security, sécurité au niveau des lignes).
|
||||
|
||||
RLS permet aux développeurs de définir des politiques de sécurité fines sur les tables de la base de données, en contrôlant avec précision, selon l'identité de l'utilisateur, quelles lignes de données il peut consulter ou modifier.
|
||||
|
||||
Lorsque vous activez RLS sur une table, toutes les requêtes de données déclenchent une vérification RLS : l'opération ne peut être exécutée que si elle passe avec succès au moins une politique de sécurité.
|
||||
|
||||
Dans Supabase, RLS est profondément intégré au système d'authentification des utilisateurs. La fonction dédiée `auth.uid()` retourne directement l'identifiant unique de l'utilisateur connecté, permettant d'associer précisément les lignes de données à l'identité de l'utilisateur.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# 3. Première application SQL
|
||||
|
||||
Après avoir maîtrisé les opérations de base sur les bases de données et RLS, nous entamons la phase pratique avec le scénario « gestion des commandes d'un restaurant de hamburgers ».
|
||||
|
||||
## 3.1 Cloner et exécuter le projet exemple Supabase
|
||||
|
||||
Clonez le dépôt suivant : https://github.com/THU-SIGS-AIID/Project5-Supabase-Demos
|
||||
|
||||
|
||||
|
||||
## 3.2 Projet 1 -- CRUD du menu du restaurant de hamburgers
|
||||
|
||||
Apprenez à initialiser la base de données via un script SQL et à connecter le projet frontend à Supabase.
|
||||
|
||||
### Créer la base de données avec un script
|
||||
|
||||
Exécutez le script `init.sql` du dossier `scripts` dans le SQL Editor.
|
||||
|
||||
### Configurer la connexion à la base de données
|
||||
|
||||
1. Via les variables d'environnement : créez un fichier `.env` avec `NEXT_PUBLIC_SUPABASE_URL` et `NEXT_PUBLIC_SUPABASE_ANON_KEY`.
|
||||
2. Via la page du projet : cliquez sur le bouton Paramètres en haut à droite.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 📚 Exercice
|
||||
|
||||
1. Essayez d'ajouter et de supprimer des éléments existants, observez les changements dans le Table Editor.
|
||||
|
||||
## 3.4 Projet 2 -- Restaurant de hamburgers avec authentification des utilisateurs
|
||||
|
||||
Le Projet 2 introduit l'authentification (Auth) et la gestion des permissions RLS, avec une page de connexion indépendante supportant « email + mot de passe ».
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 📚 Exercice
|
||||
|
||||
1. Récupérez le cadeau de bienvenue, effectuez un achat.
|
||||
2. Trouvez la table des permissions utilisateur et modifiez-les en `admin`.
|
||||
3. Localisez la table du portefeuille et augmentez le solde.
|
||||
|
||||
# 4. Construire votre première application Supabase
|
||||
|
||||
## 4.1 Processus standardisé pour connecter n'importe quelle application à Supabase
|
||||
|
||||
1. Clarifiez les besoins et décrivez-les à l'IA.
|
||||
2. Générez un script `init.sql` adapté à Supabase.
|
||||
3. Restructurez le code pour interagir avec Supabase.
|
||||
4. Configurez les paramètres de connexion et testez.
|
||||
|
||||
## 4.2 Étude de cas : construire un jeu du serpent en ligne
|
||||
|
||||
Pratiquez avec le projet `Project5-Supabase-Demos/apps_snakegame` : ajoutez un classement des scores avec connexion utilisateur.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 📚 Exercice
|
||||
|
||||
1. Intégrez le système de gestion des utilisateurs dans le jeu du serpent.
|
||||
2. Intégrez le système de gestion des utilisateurs dans votre propre application.
|
||||
|
||||
# 5. Devenir un expert Supabase
|
||||
|
||||
## 5.1 Pourquoi avons-nous choisi Supabase
|
||||
|
||||
Supabase empaquette les capacités backend en services prêts à l'emploi (PostgreSQL, Realtime, Auth, Storage, Edge Functions, API auto-générées), permettant aux équipes de se concentrer sur le développement des fonctionnalités clés. Sa stratégie entièrement open source, avec support du déploiement privé, évite le verrouillage fournisseur.
|
||||
|
||||
## 5.2 Connexion Google et GitHub
|
||||
|
||||
Le projet `project-burger-shop-auth-advanced-supabase-6` démontre ces fonctionnalités avancées.
|
||||
|
||||
|
||||
|
||||
### 5.2.1 Flux OAuth : comment fonctionne la connexion tierce
|
||||
|
||||
Le protocole OAuth 2.0 permet à l'utilisateur d'autoriser notre application à accéder à ses informations publiques sur une plateforme tierce sans exposer son mot de passe.
|
||||
|
||||
|
||||
|
||||
### 5.2.2 Configurer Google Cloud
|
||||
|
||||
Créez un OAuth 2.0 Client ID dans Google Cloud Console.
|
||||
|
||||
|
||||
|
||||
### 5.2.3 Configurer GitHub
|
||||
|
||||
Enregistrez une application OAuth dans GitHub Developer Settings.
|
||||
|
||||
|
||||
|
||||
### 5.2.4 Configurer les Providers dans Supabase
|
||||
|
||||
Activez Google et GitHub dans Authentication > Providers.
|
||||
|
||||
|
||||
|
||||
### 5.2.6 Réinitialisation du mot de passe
|
||||
|
||||
Le projet inclut la réinitialisation de mot de passe via `supabase.auth.resetPasswordForEmail()`.
|
||||
|
||||
|
||||
|
||||
## 5.3 Fonctionnalités temps réel
|
||||
|
||||
Le projet `project-burger-shop-realtime-orders-3` illustre les capacités Realtime : Postgres Changes, Broadcast et Presence.
|
||||
|
||||
|
||||
|
||||
### 5.3.1 Postgres Changes -- Modifications en temps réel
|
||||
|
||||
Permet de s'abonner aux événements INSERT, UPDATE, DELETE sur des tables spécifiques.
|
||||
|
||||
### 5.3.2 Broadcast & Presence
|
||||
|
||||
- Presence : suivi des utilisateurs en ligne.
|
||||
- Broadcast : messages temporaires à faible latence entre clients.
|
||||
|
||||
## 5.4 Stockage (Storage)
|
||||
|
||||
Le projet `project-burger-shop-storage-uploads-4` démontre le système de fichiers avec Supabase Storage.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 5.4.1 Buckets de stockage
|
||||
|
||||
Les fichiers sont organisés en Buckets avec des politiques de sécurité.
|
||||
|
||||
### 5.4.2 URLs de fichiers
|
||||
|
||||
- Public URL : lien permanent pour les ressources publiques.
|
||||
- Signed URL : lien temporaire sécurisé (recommandé en production).
|
||||
|
||||
## 5.5 Edge Functions
|
||||
|
||||
Le projet `project-burger-shop-edge-function-5` montre une conversation LLM en streaming via Edge Functions.
|
||||
|
||||
|
||||
|
||||
### 5.5.1 Cas LLM Chat
|
||||
|
||||
L'Edge Function agit comme proxy sécurisé entre le frontend et l'API OpenAI.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 5.6 Connexion Clerk
|
||||
|
||||
Clerk est un outil d'authentification professionnelle. Le projet `project-burger-shop-auth-advanced-clerk-7` illustre son intégration avec Supabase.
|
||||
|
||||
|
||||
|
||||
### 5.6.1 Créer une application Clerk
|
||||
|
||||
Visitez [dashboard.clerk.com](https://dashboard.clerk.com/) pour créer votre application.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 5.6.2 Intégration native Supabase-Clerk
|
||||
|
||||
Configurez l'intégration dans Clerk Dashboard > Integrations > Supabase.
|
||||
|
||||
### 5.6.3 Synchronisation des utilisateurs via Webhook
|
||||
|
||||
Utilisez un Edge Function Supabase pour recevoir les Webhooks Clerk et synchroniser les utilisateurs.
|
||||
|
||||
|
||||
|
||||
### 5.6.4 Connexion tierce avec Clerk
|
||||
|
||||
Clerk différencie les environnements de développement et de production pour les connexions sociales.
|
||||
|
||||
# 6. De Supabase aux autres composants backend (avancé)
|
||||
|
||||
Supabase couvre l'essentiel, mais chaque capacité (Auth, Storage, Edge Functions, Realtime, Database) a des alternatives spécialisées sur le marché.
|
||||
|
||||
## Plateformes BaaS similaires
|
||||
|
||||
| Plateforme | Type | Gratuité/Prix | Caractéristiques |
|
||||
| --- | --- | --- | --- |
|
||||
| Firebase | BaaS complet | Spark gratuit, Blaze à l'usage | Le plus mature, bonne documentation |
|
||||
| Supabase | BaaS open source | 500Mo DB, 1Go Storage | Le plus proche de Firebase en SQL |
|
||||
| Appwrite Cloud | BaaS open source | Basique gratuit | Moderne, auto-hébergeable |
|
||||
| Nhost | Postgres + GraphQL | 1Go DB, 1Go Storage | Type « Supabase + Hasura » |
|
||||
| AWS Amplify | BaaS AWS | Hosting + Cognito 10k MAU | Complet mais complexe |
|
||||
|
||||
## Authentification (Auth)
|
||||
|
||||
| Outil | Caractéristiques | Gratuité |
|
||||
| --- | --- | --- |
|
||||
| Firebase Auth | Google BaaS, 50k MAU | Spark gratuit |
|
||||
| Auth0 (Okta) | Entreprise, SSO, MFA | 25k MAU gratuit |
|
||||
| AWS Cognito | AWS natif | 10k MAU/mois |
|
||||
| Logto | Open source | 50k MAU cloud gratuit |
|
||||
| Keycloak | Open source IAM | Entièrement gratuit (auto-hébergé) |
|
||||
|
||||
## Stockage de fichiers (Storage)
|
||||
|
||||
| Plateforme | Type | Gratuité |
|
||||
| --- | --- | --- |
|
||||
| Amazon S3 | Stockage cloud AWS | 5Go, 20k requêtes/mois |
|
||||
| Google Cloud Storage | Stockage cloud Google | 1Go via Firebase |
|
||||
| MinIO | S3 compatible open source | Gratuit (auto-hébergé) |
|
||||
| Cloudinary | Média + CDN | 25Go bande passante/mois |
|
||||
|
||||
## Edge Functions
|
||||
|
||||
| Plateforme | Caractéristiques | Gratuité |
|
||||
| --- | --- | --- |
|
||||
| Cloudflare Workers | Distribué mondial | 100k requêtes/jour |
|
||||
| Vercel Edge Functions | Intégration Next.js | 1M appels/mois |
|
||||
| Netlify Edge | Node.js + Edge | ~1M requêtes/mois |
|
||||
| AWS Lambda@Edge | AWS Serverless | 1M requêtes/mois |
|
||||
|
||||
## Temps réel (Realtime)
|
||||
|
||||
| Plateforme | Caractéristiques | Gratuité |
|
||||
| --- | --- | --- |
|
||||
| Firebase Realtime DB | Google BaaS temps réel | 1Go stockage |
|
||||
| Ably | Pub/sub temps réel | 6M messages/mois |
|
||||
| Pusher Channels | WebSocket service | 200k messages/jour |
|
||||
| Socket.IO (auto-hébergé) | Flexibilité maximale | Coût serveur |
|
||||
|
||||
## Bases de données
|
||||
|
||||
| Plateforme | Type | Gratuité |
|
||||
| --- | --- | --- |
|
||||
| Neon | Serverless PostgreSQL | 0.5Go, branches |
|
||||
| Aiven PostgreSQL | PostgreSQL managé | 1Go stockage |
|
||||
| CockroachDB Cloud | SQL distribué | 10Go stockage |
|
||||
| TiDB Cloud | MySQL compatible distribué | 25Go max |
|
||||
| MongoDB Atlas | NoSQL document | 0.5Go stockage |
|
||||
|
||||
# Résumé
|
||||
|
||||
Dans ce cours, nous avons systématiquement appris les concepts fondamentaux des bases de données, la définition et les opérations détaillées de Supabase. Vous pourrez vous référer à ce document à tout moment lors de vos projets ultérieurs.
|
||||
|
||||
Rappelez-vous toujours un principe important : **Terminez d'abord, perfectionnez ensuite !** Nul besoin de viser la perfection du premier coup -- nous pouvons toujours nous améliorer par itérations successives. Bonne chance dans vos projets pratiques !
|
||||
|
||||
# 📚 Exercice final
|
||||
|
||||
1. Développez une application intégrant un système de gestion des utilisateurs et une base de données. Idéalement avec davantage de fonctionnalités Supabase (Realtime / Cloud Storage / Edge Function).
|
||||
@@ -0,0 +1,261 @@
|
||||
# Flux de travail Git et GitHub
|
||||
|
||||
Dans les cours précédents, nous avons appris à écrire du code en utilisant des outils de vibe coding basés sur le web. Chaque conversation crée une nouvelle version du code. Mais réfléchissons à une question : si nous voulons revenir à une modification précédente, existe-t-il une méthode pratique ? Y a-t-il un outil capable d'enregistrer notre code à différents stades, nous permettant de basculer et de modifier librement entre les versions ?
|
||||
|
||||
Pour répondre à ce besoin, les logiciels de contrôle de version sont apparus. Dans cet article, nous présenterons le programme de contrôle de version le plus célèbre — Git — ainsi que la meilleure plateforme d'hébergement de code — GitHub. Nous apprendrons à utiliser Git pour la gestion de code, comment récupérer le code d'autres personnes depuis GitHub, comment télécharger notre propre code, et comment collaborer avec d'autres sur des projets d'envergure.
|
||||
|
||||
Que ce soit pour le suivi de versions de projets personnels, la synchronisation de code dans la collaboration en équipe, ou la contribution à la communauté open source, Git et GitHub sont des outils indispensables pour les développeurs modernes. En les maîtrisant, vous serez capable de gérer votre code plus efficacement, de créer des points de contrôle selon vos besoins, de naviguer librement entre les différentes étapes du code, et de traiter facilement tout, de la modification d'un seul fichier au développement de projets d'envergure — rendant chaque itération de code contrôlable et traçable.
|
||||
|
||||
> 💡 **Prérequis**
|
||||
>
|
||||
> Avant d'apprendre Git, il est recommandé de connaître les concepts suivants :
|
||||
> - [Qu'est-ce que le terminal/la ligne de commande](/fr-fr/appendix/2-development-tools/command-line-shell) - Apprendre à interagir avec l'ordinateur via la ligne de commande
|
||||
> - [Qu'est-ce que Git](/fr-fr/appendix/2-development-tools/git-version-control) - Comprendre les concepts clés du système de contrôle de version Git
|
||||
>
|
||||
> Cet article se concentrera sur le flux de travail GitHub et les opérations pratiques. Les connaissances de base mentionnées ci-dessus sont disponibles via les liens de l'annexe.
|
||||
|
||||
# Démarrage rapide avec Git
|
||||
|
||||
Avant de commencer à utiliser Git, assurez-vous d'avoir lu le contenu de l'annexe sur la [ligne de commande](/fr-fr/appendix/2-development-tools/command-line-shell) et les [bases de Git](/fr-fr/appendix/2-development-tools/git-version-control). Cet article suppose que vous possédez déjà ces connaissances de base et abordera directement l'installation, la configuration de Git et l'utilisation de GitHub pour la collaboration.
|
||||
|
||||
## Comment installer Git
|
||||
|
||||
Nous démontrerons trois méthodes d'installation de Git sur différents systèmes d'exploitation. Veuillez suivre les instructions correspondant à votre version du système :
|
||||
|
||||
### Windows
|
||||
|
||||
1. Allez sur la [page de téléchargement officielle de Git](https://git-scm.com/download/win) et téléchargez le programme d'installation adapté à votre système : [Installateur](https://github.com/git-for-windows/git/releases/download/v2.51.0.windows.1/Git-2.51.0-64-bit.exe). Par défaut, l'installateur x64 est recommandé.
|
||||
2. Double-cliquez sur le programme d'installation et suivez les instructions de l'assistant d'installation :
|
||||
|
||||
1. Il est recommandé de conserver les options par défaut. Si vous souhaitez personnaliser, notez les points suivants (dans la plupart des cas, vous pouvez simplement cliquer sur « Next ») :
|
||||
- Choisir l'éditeur par défaut utilisé par Git : sélectionnez votre éditeur préféré (comme VS Code). Vous pouvez garder le premier choix par défaut, Vim (un éditeur de texte), ou choisir l'option « Visual Studio Code as Git's default editor » (nécessite l'installation préalable de VS Code). Vous pouvez garder la sélection par défaut et cliquer « Next » pour continuer.
|
||||
|
||||
- Choisir comment utiliser Git : ces trois options contrôlent l'accessibilité de Git sur le système. L'option 2 est recommandée (« from command line and 3rd-party software ») — elle ajoute les outils Git de base au PATH, vous permettant d'utiliser Git dans Git Bash, l'invite de commandes, PowerShell et les IDE, sans surcharger le système.
|
||||
|
||||
|
||||
3. Après l'installation, faites un clic droit sur le bureau. Si vous voyez « Git Bash Here » dans le menu, l'installation a réussi.
|
||||
|
||||
|
||||
|
||||
### MacOS
|
||||
|
||||
Pour macOS, vous pouvez d'abord taper `git --version` dans le terminal pour vérifier si Git est déjà installé. Si ce n'est pas le cas, le système vous invitera à l'installer — suivez simplement les instructions.
|
||||
|
||||
1. Méthode 1 : Installation via Homebrew
|
||||
Si vous avez installé [Homebrew](https://brew.sh/) (le gestionnaire de paquets Mac), ouvrez le terminal et tapez
|
||||
```bash
|
||||
brew install git
|
||||
```
|
||||
2. Méthode 2 : (Recommandée) Installation via Xcode : https://developer.apple.com/xcode/ , Xcode inclut Git. Après l'installation, suivez simplement les instructions.
|
||||
|
||||
### Linux
|
||||
|
||||
La plupart des distributions Linux peuvent installer Git via leur gestionnaire de paquets :
|
||||
|
||||
- Ubuntu/Debian :
|
||||
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt install git
|
||||
```
|
||||
|
||||
- CentOS/RHEL :
|
||||
|
||||
```bash
|
||||
sudo yum install git
|
||||
```
|
||||
|
||||
- Vérification de l'installation : tapez `git --version` dans le terminal. Si le numéro de version s'affiche, l'installation a réussi.
|
||||
|
||||
## Initialisation de Git
|
||||
|
||||
Après avoir installé Git, vous devez d'abord configurer vos informations utilisateur — c'est l'étape fondamentale pour utiliser le contrôle de version Git. Exécutez les commandes suivantes dans le terminal (remplacez le contenu entre crochets par vos propres informations) :
|
||||
|
||||
```bash
|
||||
# Définir le nom d'utilisateur global (apparaîtra dans les enregistrements de commit)
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
# Définir l'e-mail global (il est recommandé d'utiliser l'e-mail enregistré sur GitHub/GitLab)
|
||||
git config --global user.email "your.email@example.com"
|
||||
```
|
||||
|
||||
Git intègrera ces informations dans chaque enregistrement de commit, comme « informations d'auteur » de chaque modification. Lorsque vous consultez l'historique des versions (par exemple avec `git log`), vous pouvez clairement voir qui a modifié chaque ligne de code, facilitant la traçabilité des responsabilités et la communication. Dans les projets collaboratifs, des informations d'identité unifiées permettent aux membres de l'équipe d'identifier rapidement qui a effectué quelles modifications, améliorant l'efficacité de collaboration (par exemple, trouver le développeur concerné via les enregistrements de commit pour discuter d'un problème).
|
||||
|
||||
Vous pouvez vérifier vos informations de configuration Git actuelles en tapant `git config --list` dans la ligne de commande, pour confirmer que la configuration a réussi.
|
||||
|
||||
# Qu'est-ce que GitHub
|
||||
|
||||
GitHub est une plateforme d'hébergement de code basée sur Git. Elle offre non seulement un stockage distant pour les dépôts Git, mais inclut également des outils de collaboration (comme Issues, Pull Requests, Projects) qui facilitent le partage de code et la collaboration entre développeurs. En bref, Git est un outil de contrôle de version local, tandis que GitHub est un « cloud de dépôts de code + communauté de collaboration » distant.
|
||||
|
||||
GitHub n'est pas seulement la plus grande plateforme d'hébergement de code au monde, c'est aussi la communauté open source la plus active et la plus influente au niveau mondial. L'idée centrale de l'« open source » est que n'importe qui peut télécharger et exécuter le code source du logiciel. Ce modèle permet à des personnes du monde entier d'examiner le code des autres, de le modifier ou de créer de nouveaux projets à partir de celui-ci. Par exemple, vous pouvez trouver sur GitHub toutes sortes de tutoriels d'apprentissage ainsi que le code source complet de frameworks d'entraînement de modèles GPT (comme PyTorch). Chaque jour, d'innombrables personnes collaborent à l'échelle mondiale pour examiner et améliorer le code.
|
||||
|
||||
|
||||
|
||||
De nombreuses grandes entreprises publient en open source leurs programmes ou tutoriels sur GitHub pour obtenir un avantage concurrentiel dans l'industrie — ce qui peut aussi être vu comme une forme de publicité. Dans la communauté GitHub, le nombre d'« étoiles (stars) » obtenues par un projet est l'indicateur principal de sa valeur ; plus un projet ou une organisation possède d'étoiles, plus sa crédibilité et son influence sont grandes.
|
||||
|
||||
|
||||
|
||||
Dans notre cours, les ressources de support et les devoirs seront également téléchargés sur un dépôt GitHub dédié. À travers le processus de soumission des devoirs, vous vous familiariserez progressivement avec l'utilisation de GitHub, posant ainsi des bases solides pour le contrôle de version dans le développement futur d'applications.
|
||||
|
||||
## Créer un compte GitHub
|
||||
|
||||
1. Visitez le [site officiel de GitHub](https://github.com/) et cliquez sur « Sign up » en haut à droite.
|
||||
|
||||
2. Entrez votre adresse e-mail (il est recommandé d'utiliser une adresse courante, car les vérifications et notifications y seront envoyées), définissez un mot de passe (doit contenir des lettres, des chiffres et des caractères spéciaux).
|
||||
3. Complétez la vérification humaine, vérifiez votre e-mail selon les instructions, et votre compte sera créé.
|
||||
|
||||
## Créer votre premier dépôt sur GitHub
|
||||
|
||||
Ensuite, nous allons créer notre premier dossier de stockage, aussi appelé dépôt ou « repo ».
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. Repository name : le nom du dépôt visible par les autres.
|
||||
2. Description : une description détaillée du dépôt.
|
||||
3. Choose visibility : pour un dépôt personnel, si vous le définissez comme privé, seuls vous et les personnes spécialement invitées pouvez le voir. Si vous le définissez comme public, tout le monde peut le voir.
|
||||
Pour les dépôts d'organisation, si c'est Privé, seuls les membres de l'organisation peuvent le voir.
|
||||
Si c'est Public, les personnes extérieures à l'organisation peuvent également le voir.
|
||||
4. README : il est d'usage que chaque dépôt possède un fichier README. Vous pouvez le considérer comme la présentation complète du dépôt, incluant les instructions d'utilisation, la liste des fichiers et les méthodes de fonctionnement.
|
||||
5. Add .gitignore and license :
|
||||
1. Le fichier .gitignore indique à Git d'ignorer certains dossiers ou fichiers lors du téléchargement vers GitHub, ils ne seront donc pas suivis ni ajoutés à la zone de staging. Cela est utile pour les fichiers de test temporaires, les packages de dépendances ou les fichiers volumineux. Une fois spécifiés, ces fichiers ne seront plus suivis.
|
||||
2. License fait référence au type de licence open source que vous choisissez. Différentes licences détaillent si d'autres personnes peuvent utiliser votre code à des fins commerciales, et incluent d'autres clauses et conditions.
|
||||
|
||||
Il est recommandé de cocher « Add README », de définir la visibilité du dépôt sur « Private », de remplir le nom et la description du dépôt selon vos préférences, puis de cliquer sur « Create repository » pour terminer la création de votre premier dépôt distant.
|
||||
|
||||
|
||||
|
||||
Vous disposerez ensuite d'un dépôt propre sans fichiers supplémentaires. Vous pouvez maintenant commencer à télécharger des fichiers.
|
||||
|
||||
|
||||
|
||||
La commande pour obtenir le dépôt est `git clone`, mais elle nécessite l'adresse du dépôt. Vous pouvez trouver cette adresse en cliquant sur le bouton vert « Code », où vous verrez les options HTTPS et SSH. En général, vous pouvez utiliser l'une ou l'autre méthode pour télécharger le dépôt sur votre machine locale (c'est la seule façon de modifier et de télécharger des fichiers).
|
||||
|
||||
|
||||
|
||||
En règle générale, le clonage via HTTP est adapté au téléchargement temporaire et au test des dépôts d'autres personnes, mais n'est pas recommandé pour votre propre développement. Pour une meilleure expérience d'apprentissage, vous devriez d'abord configurer l'authentification SSH.
|
||||
|
||||
## Lier le SSH local
|
||||
|
||||
Dans GitHub, la « liaison du protocole SSH » signifie essentiellement associer la clé publique SSH de votre appareil local à votre compte GitHub, permettant à GitHub d'identifier votre appareil via le protocole SSH. Cela vous permet d'opérer de manière sécurisée sur les dépôts distants (cloner, pousser ou tirer du code) sans avoir besoin de mot de passe.
|
||||
|
||||
En termes simples : c'est comme donner à votre appareil un « badge d'accès GitHub dédié ». Une fois lié, lorsque votre appareil accède aux dépôts GitHub via le protocole SSH, GitHub vérifie ce « badge d'accès » (votre clé publique SSH). Une fois confirmé comme appareil autorisé, vous pouvez opérer directement — sans avoir à saisir votre nom d'utilisateur et votre mot de passe à chaque fois.
|
||||
|
||||
> 💡 Qu'est-ce que SSH
|
||||
|
||||
### Pourquoi la liaison du protocole SSH est-elle nécessaire ?
|
||||
|
||||
GitHub prend en charge deux principaux protocoles d'opération des dépôts : le protocole HTTPS et le protocole SSH :
|
||||
|
||||
- Protocole HTTPS : chaque opération (comme push) nécessite de saisir le nom d'utilisateur et le mot de passe GitHub (ou un Personal Access Token PAT). Le processus de vérification est fastidieux et comporte un risque de fuite de mot de passe.
|
||||
- Protocole SSH : l'authentification est effectuée via une « paire de clés », il n'est donc pas nécessaire de saisir le mot de passe à plusieurs reprises, et la transmission chiffrée est plus sécurisée.
|
||||
|
||||
La « liaison du protocole SSH » est une étape préalable à l'activation de l'authentification SSH GitHub — ce n'est qu'après avoir « lié » votre clé publique SSH locale à votre compte GitHub que GitHub pourra identifier votre appareil et autoriser les opérations SSH sur les dépôts.
|
||||
|
||||
### Logique centrale de la « liaison » : le rôle de la paire de clés SSH
|
||||
|
||||
L'authentification SSH repose sur une paire de clés (clé publique + clé privée), qui sont des fichiers chiffrés correspondants. Après les avoir générées, vous devez fournir la « clé publique » à GitHub (la « liaison »), tandis que la « clé privée » reste sur votre appareil local :
|
||||
|
||||
1. Clé privée : stockée dans un répertoire spécifié de votre appareil local (généralement ~/.ssh/), agissant comme « votre clé personnelle » — à ne jamais partager avec qui que ce soit.
|
||||
2. Clé publique : c'est une « serrure » partageable publiquement — vous devez la copier dans la « liste des clés SSH » de votre compte GitHub (l'opération de « liaison »).
|
||||
|
||||
Lorsque vous opérez sur un dépôt GitHub via SSH (par exemple `git push git@github.com:xxx/xxx.git`) :
|
||||
|
||||
- Votre appareil local utilise la clé privée pour chiffrer la « requête d'opération » et l'envoie à GitHub ;
|
||||
- Après réception de la requête, GitHub tente de la déchiffrer avec la clé publique que vous avez précédemment liée ;
|
||||
- Si le déchiffrement réussit, votre appareil est confirmé comme autorisé et l'opération est permise ; sinon, l'accès est refusé.
|
||||
|
||||
### Étapes spécifiques de la « liaison » (flux principal)
|
||||
|
||||
Une fois que vous avez compris le principe, l'opération pratique est simple — le cœur est « générer une paire de clés → télécharger la clé publique sur GitHub » :
|
||||
|
||||
1. Générer une paire de clés SSH localement
|
||||
1. Utiliser Trae pour obtenir la clé publique (recommandé)
|
||||
Prompt : `Help me create the SSH key needed for GitHub login. My email is your_email@gmail.com , Please return the public key for me to copy`
|
||||
|
||||
|
||||
|
||||
Après avoir entré le prompt, vous devez également appuyer sur la touche Entrée dans le terminal de gauche, sinon la commande restera en attente sans s'exécuter. Comme Trae ne peut pas exécuter de jugements conditionnels pour vous, il suffit d'appuyer sur Entrée jusqu'à ce que le processus se termine.
|
||||
|
||||
Enfin, vous verrez que Trae à droite a renvoyé la clé publique qu'il a lue. Il vous suffit de la copier et de vous préparer à la coller à l'étape suivante.
|
||||
|
||||
 2. Obtenir manuellement la clé publique
|
||||
Ouvrez votre terminal local (Git Bash ou PowerShell sur Windows ; Terminal sur macOS/Linux) et entrez la commande suivante (remplacez your_email@example.com par l'e-mail utilisé pour votre inscription GitHub) :
|
||||
|
||||
```bash
|
||||
ssh-keygen -t ed25519 -C "your_email@example.com"
|
||||
```
|
||||
|
||||
1. Appuyez sur Entrée pour accepter les valeurs par défaut (chemin de fichier par défaut, sans phrase de passe, ou définissez-en une si nécessaire). Cela générera deux fichiers dans le répertoire ~/.ssh/ :
|
||||
- id_ed25519 : clé privée (stockée localement, **à ne jamais partager**) ;
|
||||
- id_ed25519.pub : clé publique (à télécharger sur GitHub).
|
||||
|
||||
2. « Lier » la clé publique à votre compte GitHub
|
||||
|
||||
C'est l'étape centrale de la liaison — ajouter la clé publique locale à la « liste des clés SSH » de votre compte GitHub :
|
||||
|
||||
1. Copier le contenu de la clé publique :
|
||||
1. Via Trae :
|
||||
2. Windows : ouvrez C:\Users\<your>\.ssh\id_ed25519.pub avec le Bloc-notes et copiez tout son contenu ;
|
||||
3. macOS/Linux : exécutez `cat ~/.ssh/id_ed25519.pub` dans le terminal et copiez toute la sortie (depuis le début SSH-ed25519 jusqu'à l'e-mail à la fin).
|
||||
2. Connectez-vous à GitHub et accédez à la page « SSH Key Management » :
|
||||
1. Cliquez sur l'avatar en haut à droite → Settings → menu latéral SSH and GPG keys → cliquez sur New SSH key.
|
||||
|
||||
2. Saisissez n'importe quel titre (par exemple, SSH de votre ordinateur local), puis collez la clé publique SSH que vous venez d'obtenir.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. Vérifier que la liaison a réussi
|
||||
|
||||
Tapez la commande suivante dans le terminal (**Trae peut également effectuer les opérations suivantes**) pour tester si GitHub peut identifier votre appareil :
|
||||
|
||||
```bash
|
||||
ssh -T git@github.com
|
||||
```
|
||||
|
||||
- Si vous voyez un message du type « Hi [votre nom d'utilisateur GitHub] ! You've successfully authenticated... », cela signifie que votre clé a été liée avec succès ;
|
||||
- Si vous rencontrez une erreur, c'est généralement parce que la clé publique a été copiée de manière incomplète, que les permissions de la clé privée sont trop larges (votre répertoire ~/.ssh/ local ne doit être accessible qu'en lecture/écriture pour vous), etc. Vérifiez ces points si nécessaire.
|
||||
|
||||
### Remarques importantes
|
||||
|
||||
Si vous avez plusieurs appareils (comme un ordinateur portable et un ordinateur de bureau), vous devez générer une paire de clés SSH distincte pour chaque appareil et lier chaque clé publique au même compte GitHub — chaque appareil a son propre « badge d'accès ».
|
||||
|
||||
Ne partagez jamais votre clé privée (ne la téléchargez pas sur GitHub et ne la partagez pas avec d'autres), sinon quelqu'un pourrait se faire passer pour vous et opérer sur vos dépôts. Si la clé privée est compromise, supprimez immédiatement la clé publique correspondante de GitHub et générez une nouvelle paire de clés.
|
||||
|
||||
Après avoir lié SSH, utilisez les adresses de dépôt au format SSH (par exemple `git@github.com:username/repository.git`) pour vos opérations, et non le format HTTPS (par exemple `https://github.com/username/repository.git`). Si vous avez précédemment cloné le dépôt via HTTPS, vous pouvez changer de protocole avec `git remote set-url origin <new>`.
|
||||
|
||||
# Utiliser Trae pour les opérations GitHub
|
||||
|
||||
Nous avons expliqué ce qu'est Git, ce qu'est GitHub, ce qu'est SSH et comment le configurer. Vous pouvez maintenant utiliser librement Trae pour effectuer des opérations Git. Commençons par apprendre à cloner un dépôt distant sur votre machine locale.
|
||||
|
||||
## Git clone : télécharger un dépôt existant
|
||||
|
||||
Vous pouvez directement lui indiquer l'adresse du dépôt que vous souhaitez cloner
|
||||
|
||||
|
||||
|
||||
## Git pull : récupérer les mises à jour du dépôt distant
|
||||
|
||||
Avant chaque mise à jour du dépôt, comme il peut être maintenu par plusieurs personnes, vous devez d'abord tirer les dernières modifications. Ensuite, vous pouvez modifier et pousser les fichiers.
|
||||
|
||||
**N'oubliez pas d'inclure le nom du dossier et son chemin relatif ou absolu, pour éviter de pousser vers le mauvais dépôt.**
|
||||
|
||||
prompt : `Help me pull this repository AIID-TEST in ./AIID-TEST.`
|
||||
|
||||
## Git commit & Git push : staging des mises à jour et push vers GitHub
|
||||
|
||||
Une fois que tout est prêt, vous pouvez essayer de modifier les fichiers locaux, d'ajouter ou de supprimer des éléments dans le dossier. Ensuite, demandez à Trae de détecter les modifications et de vous aider à les pousser vers GitHub.
|
||||
|
||||
prompt : `I finished. Commit and push to the repository AIID-TEST in ./AIID-TEST.`
|
||||
|
||||
|
||||
|
||||
Le push a réussi. Vous pouvez maintenant voir le contenu mis à jour sur GitHub.
|
||||
|
||||
# Ressources de référence
|
||||
|
||||
- Pro Git book https://git-scm.com/book/en/v2
|
||||
- GitHub Docs https://docs.github.com/en
|
||||
@@ -0,0 +1,800 @@
|
||||
# Outils de programmation IA en ligne de commande (CLI)
|
||||
|
||||
Dans ce tutoriel, nous présenterons les agents de programmation IA qui s'exécutent directement dans la ligne de commande. Contrairement aux agents intégrés dans Trae ou Cursor que vous avez déjà étudiés, les outils CLI de programmation IA fonctionnent uniquement dans le terminal. Par rapport aux agents intégrés aux IDE IA, ils disposent généralement d'une fenêtre de contexte plus longue, d'une vitesse d'appel d'outils plus rapide et sont compatibles avec un plus grand nombre de modèles de langage. Dans les pratiques les plus récentes de l'AI Vibe Coding, nous privilégions souvent les outils CLI de programmation IA plutôt que les agents de codage intégrés à l'IDE.
|
||||
|
||||
## En partant du CLI
|
||||
|
||||
Vous vous souvenez du CLI que nous avons présenté précédemment ? Le CLI (Command Line Interface) désigne l'utilisation d'un terminal ou d'une invite de commande pour interagir avec des logiciels via des commandes en texte brut, plutôt que par le biais d'une interface graphique (GUI -- que vous pouvez comprendre comme les interfaces avec des boutons sur ordinateur ou smartphone, où il suffit de cliquer sans taper de commandes).
|
||||
|
||||
> Sous Windows, les terminaux les plus courants sont l'« Invite de commandes (cmd) » et « PowerShell ». Vous pouvez lancer ces programmes en tapant « cmd » ou « powershell » dans la barre de recherche ou la boîte de dialogue Exécuter.
|
||||
|
||||
|
||||
|
||||
Le CLI est naturellement adapté aux opérations par commandes textuelles. Parmi une petite minorité de geeks (passionnés de programmation en quête de performances extrêmes), le CLI est même plus populaire que le GUI -- ils souhaitent réaliser toutes les opérations au clavier, estimant que l'utilisation de la souris ralentit leur efficacité de codage.
|
||||
|
||||
Dans l'industrie, le CLI est souvent la forme d'interface la plus courante, car le GUI nécessite que le système d'exploitation génère des interfaces supplémentaires et gère les fenêtres, ce qui exige davantage de ressources informatiques ; le CLI, en revanche, se contente de transmettre les commandes reçues au système pour exécution. Ainsi, lors de la connexion à des clusters de serveurs à grande échelle, nous interagissons généralement uniquement via le CLI.
|
||||
|
||||
|
||||
|
||||
Pour beaucoup d'étudiants sans expérience en CLI, ces opérations peuvent sembler complexes, avec trop de commandes à retenir, et l'on peut même craindre de « casser son ordinateur par erreur ». Rassurez-vous. Vous souvenez-vous que dans les tutoriels précédents, nous demandions souvent à Trae d'effectuer diverses opérations de base ? Ici aussi, vous pouvez reprendre exactement la même approche -- nous pouvons laisser l'outil de programmation CLI effectuer toutes les opérations à notre place : naviguer dans les dossiers, rechercher et traiter des fichiers, exécuter ou copier des projets open source, etc. L'ensemble du processus peut être réalisé par la conversation avec l'outil de programmation IA en CLI.
|
||||
|
||||
## En quoi diffère-t-il des IDE IA ?
|
||||
|
||||
Nous pouvons comparer les outils de programmation IA en CLI avec z.ai et Trae que nous avons déjà étudiés. En un sens, un outil de programmation IA en CLI peut être considéré comme une version spéciale de z.ai : ils nécessitent tous deux une simple interface de conversation pour exécuter automatiquement toutes les opérations requises (parfois vous devrez ouvrir manuellement le navigateur pour voir le résultat final). Et si l'on compare avec les IDE IA, l'outil de programmation IA en CLI peut être vu comme le module Agent de l'IDE -- c'est-à-dire la zone de conversation dans le panneau latéral.
|
||||
|
||||
|
||||
|
||||
Cependant, comme les différents IDE IA implémentent les agents de manières différentes, avec des capacités très variables, les résultats de programmation IA sont souvent instables. C'est pourquoi les outils de programmation IA en CLI sont généralement développés directement par de grandes entreprises technologiques, telles qu'Anthropic (derrière Claude) ou OpenAI (derrière ChatGPT).
|
||||
|
||||
Par rapport aux autres agents de programmation IA, l'utilisation directe de ces produits de grands groupes est souvent une pratique plus avantageuse, d'autant plus que Claude Code est lui-même conçu pour servir l'équipe de développement interne d'Anthropic, pensé dès l'origine pour « répondre aux véritables besoins des ingénieurs ».
|
||||
|
||||
Pour une comparaison plus visuelle, examinons les différences entre Claude Code et un agent d'IDE IA typique (ici Cursor) :
|
||||
|
||||
| Fonctionnalité | Claude Code | Cursor | Avantage |
|
||||
| ----------------- | ------------- | --------------- | ----------- |
|
||||
| Exécution automatique de tâches | ✅ Excellent | ❌ Capacités limitées | Claude Code |
|
||||
| Intégration IDE | ❌ Ligne de commande uniquement | ✅ VS Code natif | Cursor |
|
||||
| Complétion de code en temps réel | ❌ Non | ✅ Excellente expérience | Cursor |
|
||||
| Opérations multi-fichiers | ✅ Excellent | ⚠️ Correct | Claude Code |
|
||||
| Opérations GitHub intégrées | ✅ Commit direct | ⚠️ Manipulation manuelle | Claude Code |
|
||||
| Courbe d'apprentissage | ⚠️ Moyenne | ✅ Prise en main facile | Cursor |
|
||||
| Longueur du contexte | ✅ Très long | ⚠️ Correct | Claude Code |
|
||||
| Assistance au débogage | ✅ Automatisée | ⚠️ Souvent manuel | Claude Code |
|
||||
|
||||
Source du tableau : <https://northflank.com/blog/claude-code-vs-cursor-comparison>
|
||||
|
||||
En résumé, les outils de programmation IA en CLI peuvent généralement :
|
||||
|
||||
- Prendre en charge des conversations continues plus longues (ils peuvent même « travailler toute une journée » pour vous).
|
||||
- Offrir une fenêtre de contexte plus étendue (vous n'aurez plus besoin de dire aussi souvent « continue »).
|
||||
- Répondre plus rapidement (ils peuvent se connecter à davantage d'API de modèles personnalisés).
|
||||
|
||||
Pour les opérations liées au codage, ils sont généralement plus intelligents et plus stables que la plupart des agents intégrés aux IDE.
|
||||
|
||||
## Outils de programmation IA en CLI les plus courants
|
||||
|
||||
Bien qu'il existe de nombreuses implémentations open source, dans la pratique nous ne recommandons que deux grandes catégories d'outils de programmation IA en CLI, comme « combinaison de premier choix ». Vous pouvez choisir celui qui vous convient le mieux selon vos habitudes, et nous vous recommandons vivement d'essayer les deux avant de choisir celui qui vous correspond le mieux.
|
||||
|
||||
- Codex utilise GPT-5, avec des capacités globales plus puissantes ;
|
||||
- Claude Code via l'API GLM 4.6 offre une expérience proche de Claude 4, mais à un prix plus abordable.
|
||||
- OpenCode permet de changer et combiner librement les modèles, propose des modèles gratuits et offre un meilleur contrôle des coûts.
|
||||
|
||||
Cependant, lequel est le plus efficace dans un projet réel ne peut être jugé que par des tests pratiques. Maîtriser plusieurs outils de programmation IA est toujours bénéfique : une fois compétent, vous pourrez passer aisément de Claude Code à Codex ou Trae selon les scénarios. Si après plusieurs essais un outil s'avère médiocre, passez simplement à un autre outil ou modèle.
|
||||
|
||||
Par ailleurs, les versions des modèles évoluent très rapidement. Nous vous conseillons de privilégier la solution offrant le meilleur rapport qualité/prix (efficacité / coût).
|
||||
|
||||
### Claude Code
|
||||
|
||||
Claude Code est un outil de programmation IA développé par Anthropic, basé sur les capacités du grand modèle Claude. Son principal espace d'interaction est le terminal, et il prend également en charge une utilisation en tant qu'extension VS Code. Comme les agents intégrés aux IDE IA, il peut analyser en profondeur le dépôt de code du développeur et accomplir des tâches de développement de bout en bout via des instructions en langage naturel -- y compris l'édition de code, la correction de bugs, l'exécution et la réparation de tests, la gestion des flux Git (par exemple la résolution de conflits de fusion, la création de PR), l'explication de code complexe, l'exécution de commandes terminal, etc.
|
||||
|
||||
|
||||
|
||||
Les avantages de Claude Code se manifestent principalement par : une fenêtre de contexte extrêmement longue (pouvant traiter des fichiers complets voire de petits projets), la capacité à clarifier proactivement les exigences ambiguës, la planification et l'allocation automatiques des tâches d'exécution, ainsi qu'une compréhension et une explication approfondies du contenu de l'ensemble du dépôt de code. Par rapport aux agents IDE classiques, il est mieux adapté à un flux de développement « immersive vibe coding ».
|
||||
|
||||
En pratique, vous pouvez lui demander via des instructions conversationnelles de créer un nouveau projet, d'exécuter des opérations CLI (par exemple organiser des dossiers, renommer des fichiers en lot, déployer des projets open source), de configurer l'environnement de développement (par exemple installer et déboguer un environnement Python). Si un extrait de code vous semble difficile à comprendre ou si la structure d'un répertoire n'est pas claire, vous pouvez également demander directement à Claude Code de générer un document d'analyse structuré, ou d'expliquer étape par étape un contenu spécifique.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Si vous souhaitez apprendre Claude Code de manière systématique, vous pouvez consulter le cours conjointement proposé par Andrew Ng et Anthropic :
|
||||
<https://www.bilibili.com/video/BV176t2zSEpr>
|
||||
|
||||
Nous allons maintenant apprendre à utiliser Claude Code. Comme le coût d'utilisation directe du Claude Code officiel est souvent très élevé (comme le montre l'image ci-dessous), nous utiliserons plutôt des plateformes API d'autres grands modèles compatibles avec le protocole Claude Code.
|
||||
|
||||
|
||||
|
||||
Vous devez apprendre les différentes approches suivantes (idéalement toutes les essayer), puis choisir celle qui vous convient le mieux comme parcours principal.
|
||||
|
||||
La première méthode consiste à utiliser directement une API « compatible avec l'interface Anthropic ». Avec la popularité de Claude Code, de plus en plus de fournisseurs de grands modèles commencent à prendre en charge le style d'appel Anthropic. Les fournisseurs courants incluent GLM, Kimi, DeepSeek et Siliconflow, qui proposent tous des API compatibles. Nous détaillerons la configuration spécifique plus loin.
|
||||
|
||||
Il convient de noter que Claude Code consomme généralement beaucoup de tokens. Si vous craignez des coûts d'appel API trop élevés, vous pouvez envisager l'abonnement mensuel GLM (environ 20 yuans/mois) pour maîtriser les coûts. Si vous souhaitez d'abord évaluer les dépenses réelles, vous pouvez commencer par recharger 10 yuans pour des tests à petite échelle.
|
||||
|
||||
Une autre approche consiste à utiliser le projet « Claude Code Route ». Il s'agit d'un outil open source qui prend en charge toutes les interfaces d'appel API courantes, vous permet de configurer finement le modèle à utiliser selon les scénarios, et prend en charge la connexion à des grands modèles déployés localement. Cependant, comme la configuration de cette solution est relativement complexe, nous vous recommandons de commencer par la première méthode.
|
||||
|
||||
#### Utiliser GLM de Zhipu comme backend (recommandé)
|
||||
|
||||
GLM (General Language Model) est une série de grands modèles de langage développée de manière autonome par Zhipu AI. GLM-4.6 est la version la plus récente de la série GLM, dont l'atout majeur réside dans ses excellentes performances en matière de code (comparable à Claude Sonnet 4 sur les benchmarks publics et les tâches réelles, se positionnant dans le premier rang en Chine).
|
||||
|
||||
|
||||
|
||||
Il a également étendu sa fenêtre de contexte à 200K, permettant de traiter plus sereinement les textes longs et les bases de code volumineuses, tout en renforçant les capacités de raisonnement et d'appel d'outils, atteignant un bon équilibre entre performances et coûts.
|
||||
|
||||
|
||||
|
||||
Avant de connecter GLM, nous devons d'abord installer Claude Code.
|
||||
|
||||
Si vous trouvez les étapes d'installation en ligne de commande fastidieuses ou rencontrez des erreurs, vous pouvez demander directement à l'agent de Trae de vous aider.
|
||||
|
||||
```python
|
||||
# Installer Claude Code
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
|
||||
# Accéder à votre projet
|
||||
cd your-awesome-project
|
||||
|
||||
# Lancer Claude Code
|
||||
claude
|
||||
|
||||
# Appuyer sur Ctrl+C pour quitter Claude
|
||||
```
|
||||
|
||||
Ensuite, nous devons modifier l'adresse de requête API par défaut de Claude Code pour qu'elle prenne en charge le service API de GLM. Vous pouvez copier directement le contenu ci-dessous et demander à Trae de créer les variables d'environnement correspondantes ; vous pouvez également choisir de les écrire de manière permanente dans les variables d'environnement système (en cas de problème, l'agent peut également vous aider à modifier).
|
||||
|
||||
Tout d'abord, vous devez obtenir votre clé API GLM et la conserver de la manière qui vous convient le mieux.
|
||||
|
||||
Version nationale : <https://bigmodel.cn/usercenter/proj-mgmt/apikeys>
|
||||
Version internationale : <https://z.ai/manage-apikey/apikey-list>
|
||||
|
||||
Si vous utilisez la **version nationale de GLM**, utilisez la configuration suivante :
|
||||
|
||||
```python
|
||||
# Exécuter les commandes suivantes dans Cmd
|
||||
# Remplacez `your_zhipu_api_key` par votre clé API obtenue
|
||||
setx ANTHROPIC_AUTH_TOKEN your_zhipu_api_key
|
||||
setx ANTHROPIC_BASE_URL https://open.bigmodel.cn/api/anthropic
|
||||
```
|
||||
|
||||
Si vous utilisez la **version internationale de GLM**, utilisez la configuration suivante :
|
||||
|
||||
```python
|
||||
# Exécuter les commandes suivantes dans Cmd
|
||||
# Remplacez également `your_zai_api_key`
|
||||
setx ANTHROPIC_AUTH_TOKEN your_zai_api_key
|
||||
setx ANTHROPIC_BASE_URL https://api.z.ai/api/anthropic
|
||||
```
|
||||
|
||||
Vous pouvez saisir une instruction similaire à celle-ci directement dans Trae :
|
||||
|
||||
⚠️ Si vous configurez les « variables d'environnement permanentes » via Trae, vous **devez redémarrer Trae** après la configuration, sinon les variables d'environnement dans son terminal intégré ne se mettront pas à jour, ce qui pourrait entraîner des erreurs de connexion ou de réseau.
|
||||
|
||||
```python
|
||||
Based on my environment variable settings:
|
||||
setx ANTHROPIC_AUTH_TOKEN your_zai_api_key
|
||||
setx ANTHROPIC_BASE_URL https://api.z.ai/api/anthropic
|
||||
|
||||
and my key(Replace it with your own key):
|
||||
681fea485851d29060cc.13gfaendggaFOhb
|
||||
|
||||
please help me configure and start Claude Code
|
||||
```
|
||||
|
||||
Vous verrez une sortie de processus similaire à celle-ci :
|
||||
|
||||
|
||||
|
||||
> 💡 Qu'est-ce qu'une variable d'environnement ?
|
||||
>
|
||||
> Les variables d'environnement sont essentiellement un ensemble d'informations de configuration « clé-valeur » stockées dans le système d'exploitation, généralement sous la forme « nom_de_variable = valeur ». Tant qu'elles sont configurées à l'avance dans le terminal ou les paramètres système, les programmes peuvent lire ces variables à tout moment pour obtenir les informations correspondantes. Comme les variables d'environnement peuvent être écrites directement dans le terminal sans modifier le code lui-même, nous stockons généralement les clés d'accès aux grands modèles dans les variables d'environnement afin d'éviter toute fuite. Le programme lui suffit de lire la variable d'environnement correspondante pour effectuer l'appel au grand modèle.
|
||||
>
|
||||
> Sous Windows, les variables d'environnement sont également souvent utilisées pour stocker les « chemins d'appel » des outils en ligne de commande, en plus des clés d'accès aux grands modèles.
|
||||
>
|
||||
> Nous savons que le terminal lui-même est un programme. Parfois, nous souhaitons lancer un programme externe depuis le terminal, par exemple taper `claude` pour démarrer Claude Code. La raison pour laquelle il suffit de taper `claude` pour l'exécuter est que le terminal lit les variables d'environnement du système, dont la variable PATH contient le répertoire où se trouve l'exécutable de Claude Code, ce qui permet au terminal de le trouver et de l'exécuter (cela équivaut à coller le chemin absolu du programme dans le terminal et à appuyer sur Entrée).
|
||||
>
|
||||
> Une variable d'environnement typique pourrait ressembler à ceci : `PATH=C:\Windows\system32;C:\Program Files\Python`. Ainsi, nous pouvons exécuter ces programmes système depuis n'importe quel chemin, par exemple en tapant simplement `python` dans la ligne de commande pour lancer l'interpréteur Python.
|
||||
>
|
||||
> Si vous souhaitez consulter les variables d'environnement actuelles du système, vous pouvez taper « variables d'environnement » dans la recherche Windows. Dans la fenêtre « Modifier les variables d'environnement système » qui s'affiche, vous verrez toutes les variables et leurs valeurs. Certaines servent à stocker les clés de modèles, d'autres à ajouter des répertoires de programmes pour faciliter les appels depuis n'importe quel chemin.
|
||||
|
||||
Vous pouvez maintenant utiliser le dernier GLM pour développer avec Claude Code. Vous pouvez essayer de réexécuter un projet précédent, ou relever à nouveau les tâches que Trae n'avait pas réussi à accomplir, et comparer les différences d'expérience.
|
||||
|
||||
🎉 Répéter le processus de « tout reprendre à zéro » n'est pas une perte de temps -- à chaque nouvelle tentative, vos compétences se renforcent.
|
||||
|
||||
En suivant exactement la même logique que pour GLM, vous pouvez également connecter facilement d'autres interfaces prenant en charge le format compatible Anthropic.
|
||||
|
||||
#### Utiliser Kimi K2 comme backend (recommandé)
|
||||
|
||||
Kimi K2 est le nouveau grand modèle de langage de nouvelle génération lancé par Moonshot AI, avec d'excellentes performances en compréhension et génération de code. Kimi K2 prend en charge une fenêtre de contexte ultra-longue (jusqu'à 200K tokens), capable de traiter facilement de grandes bases de code et des projets complexes.
|
||||
|
||||
**Avantages clés :**
|
||||
|
||||
- **Contexte ultra-long** : prend en charge une fenêtre de contexte de 200K, permettant de traiter le code d'un projet entier en une seule fois
|
||||
- **Excellentes capacités en code** : performances remarquables en génération, refactoring et débogage de code
|
||||
- **Bonne compréhension du chinois** : compréhension plus précise des besoins de programmation en chinois
|
||||
- **Appels d'outils stables** : prise en charge stable des appels de fonctions et utilisation d'outils
|
||||
|
||||
**Obtenir la clé API :**
|
||||
|
||||
Visitez <https://platform.moonshot.cn/console/account> pour vous inscrire et obtenir votre clé API.
|
||||
|
||||
**Méthode de configuration :**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://api.moonshot.cn/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=sk-YOURKEY
|
||||
```
|
||||
|
||||
#### Utiliser Minimax comme backend (recommandé)
|
||||
|
||||
Minimax est le nouveau grand modèle de langage lancé par MiniMax, avec d'excellentes performances dans les tâches de programmation. Le modèle Minimax est reconnu pour ses capacités de raisonnement exceptionnelles et la qualité de son code généré, particulièrement adapté aux scénarios de programmation complexes.
|
||||
|
||||
**Avantages clés :**
|
||||
|
||||
- **Forte capacité de raisonnement** : excellentes performances en raisonnement logique complexe et conception d'architecture de code
|
||||
- **Code de haute qualité** : code généré structuré et lisible
|
||||
- **Support multilingue** : prise en charge de la génération et conversion de code en plusieurs langages
|
||||
- **Rapidité de réponse** : API à réponse rapide, adaptée aux scénarios d'appels fréquents
|
||||
|
||||
**Obtenir la clé API :**
|
||||
|
||||
Visitez <https://platform.minimax.io/> pour vous inscrire et obtenir votre clé API.
|
||||
|
||||
**Méthode de configuration :**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=YOUR_MINIMAX_API_KEY
|
||||
export ANTHROPIC_MODEL=MiniMax-M2.7
|
||||
```
|
||||
|
||||
#### Utiliser DeepSeek comme backend (recommandé)
|
||||
|
||||
DeepSeek est un grand modèle de langage open source développé par DeepSeek, populaire auprès des développeurs pour ses excellentes capacités de code et son excellent rapport qualité-prix. DeepSeek Coder a été spécialement optimisé pour les tâches de programmation.
|
||||
|
||||
**Avantages clés :**
|
||||
|
||||
- **Capacités de code exceptionnelles** : excellentes performances en génération, compréhension et correction de code
|
||||
- **Open source et personnalisable** : modèle open source, permettant un fine-tuning selon les besoins
|
||||
- **Excellent rapport qualité-prix** : prix d'API relativement bas, adapté à une utilisation intensive
|
||||
- **Bon support du chinois** : compréhension précise des scénarios de programmation en chinois
|
||||
|
||||
**Obtenir la clé API :**
|
||||
|
||||
Visitez <https://platform.deepseek.com/usage> pour vous inscrire et obtenir votre clé API.
|
||||
|
||||
**Méthode de configuration :**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=YOU_DEEPSEEK_API_KEY
|
||||
export API_TIMEOUT_MS=600000
|
||||
export ANTHROPIC_MODEL=deepseek-chat
|
||||
export ANTHROPIC_SMALL_FAST_MODEL=deepseek-chat
|
||||
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
|
||||
```
|
||||
|
||||
#### Utiliser le Coding Plan de Volcano Engine comme backend (recommandé)
|
||||
|
||||
Volcano Engine (Volcano Engine) est la plateforme de services cloud de ByteDance, proposant des services de modèles IA de niveau entreprise. Le Coding Plan de Volcano Engine est spécialement optimisé pour les scénarios de programmation, offrant des capacités de génération de code stables et efficaces.
|
||||
|
||||
**Avantages clés :**
|
||||
|
||||
- **Stabilité de niveau entreprise** : offre un SLA (Service Level Agreement) garantissant la stabilité du service
|
||||
- **Optimisé pour le code** : optimisation spécifique pour les tâches de programmation
|
||||
- **Large choix de modèles** : prend en charge plusieurs modèles, dont Doubao-pro, Doubao-lite, etc.
|
||||
- **Accès rapide en Chine** : nœuds déployés en Chine, vitesse d'accès rapide
|
||||
|
||||
**Obtenir la clé API :**
|
||||
|
||||
Visitez <https://console.volcengine.com/ark/region:ark+cn-beijing/apiKey> pour vous inscrire et obtenir votre clé API.
|
||||
|
||||
**Méthode de configuration :**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://ark.volces.com/api/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=YOUR_VOLCANO_API_KEY
|
||||
export ANTHROPIC_MODEL=doubao-pro-32k
|
||||
```
|
||||
|
||||
#### Autres API compatibles Anthropic
|
||||
|
||||
Siliconflow :
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL="https://api.siliconflow.cn/"
|
||||
export ANTHROPIC_MODEL="moonshotai/Kimi-K2-Instruct-0905" # Vous pouvez modifier le modèle souhaité
|
||||
export ANTHROPIC_API_KEY="YOUR_SILICONCLOUD_API_KEY" # Remplacez par votre clé API
|
||||
```
|
||||
|
||||
Alibaba Cloud DashScope (Aliyuncs) : <https://help.aliyun.com/zh/model-studio/get-api-key>
|
||||
|
||||
```python
|
||||
export ANTHROPIC_BASE_URL="https://dashscope.aliyuncs.com/apps/anthropic"
|
||||
export ANTHROPIC_API_KEY="YOUR_DASHSCOPE_API_KEY"
|
||||
```
|
||||
|
||||
::: details Utiliser Claude Code Route comme backend (utilisation avancée)
|
||||
|
||||
Nous avons expliqué plus haut comment remplacer l'interface Anthropic de Claude Code par l'API officielle GLM. Voyons maintenant comment l'outil Claude Code Router permet à Claude Code de s'adapter à davantage d'API de modèles.
|
||||
|
||||
[Claude Code Router](https://github.com/musistudio/claude-code-router) est un outil d'amélioration de routage intelligent conçu spécifiquement pour Claude Code. Son rôle principal est d'aider les utilisateurs à distribuer les requêtes IA vers des modèles de différentes plateformes selon leurs besoins, avec une personnalisation avancée. Il prend en charge la connexion à des dizaines de plateformes, dont OpenRouter, DeepSeek, Ollama, Gemini, et permet également de router les tâches vers des modèles spécifiques selon les scénarios, par exemple GLM-4.5, Kimi-K2, Qwen3-Coder, etc. Par exemple, vous pouvez confier automatiquement les tâches en arrière-plan à un Ollama local pour économiser les coûts ; attribuer les tâches de texte/code longs à Gemini-2.5-Pro ; et déléguer l'explication de code à DeepSeek.
|
||||
|
||||
|
||||
|
||||
Cet outil offre également des capacités de gestion de configuration UI/CLI pratiques, et s'adapte aux formats d'API des différentes plateformes via des « convertisseurs ». Il prend en charge les intégrations automatisées telles que GitHub Actions ainsi que des extensions personnalisées, résolvant le problème du « modèle unique ne couvrant pas tous les scénarios » et des « changements fréquents de plateforme fastidieux », pour aider les utilisateurs à tirer parti des outils IA de manière plus flexible et économique.
|
||||
|
||||
|
||||
|
||||
Voici comment installer Claude Code Router. Les étapes générales sont les suivantes (vous pouvez également demander à Trae de les exécuter), pour préparer l'environnement nécessaire :
|
||||
|
||||
```markdown
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
npm install -g @musistudio/claude-code-router
|
||||
```
|
||||
|
||||
Une fois l'installation terminée, vous devez vérifier que la commande `ccr` est disponible localement. Si vous voyez une sortie similaire à celle-ci, l'installation a réussi :
|
||||
|
||||
|
||||
|
||||
Ensuite, il existe deux méthodes pour initialiser et configurer les modèles :
|
||||
|
||||
- Utiliser l'interface UI de CCR, en ouvrant dans le navigateur la page de configuration qu'il fournit ;
|
||||
- Modifier directement le fichier de configuration par défaut de CCR (l'UI ne fait en réalité que modifier le fichier de configuration, mais offre une interface plus intuitive).
|
||||
|
||||
Si vous choisissez d'utiliser l'UI CCR, vous verrez une interface similaire à celle-ci :
|
||||
|
||||
|
||||
|
||||
En cliquant sur le bouton « Add Provider », vous verrez l'interface suivante. Vous devez :
|
||||
|
||||
1. Saisir le nom du fournisseur de modèle dans le champ Name ;
|
||||
2. Remplir l'adresse de l'interface compatible OpenAI du fournisseur dans API Full URL ;
|
||||
3. Saisir la clé API de la plateforme correspondante dans API Key ;
|
||||
4. Saisir le nom du modèle dans la section Models, puis cliquer sur « Add Model » pour l'ajouter ;
|
||||
5. Enfin, cliquer sur « Save » pour enregistrer la configuration.
|
||||
|
||||
(En faisant défiler vers le bas dans l'interface, vous trouverez de nombreuses options avancées, mais vous pouvez les ignorer pour le moment.)
|
||||
|
||||
|
||||
|
||||
Voici des exemples de configuration pour DeepSeek et Kimi :
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Après avoir enregistré la configuration du modèle, vous devez également spécifier le modèle par défaut (Default) dans la section Router à droite. Cliquez sur la liste déroulante correspondante et définissez-la sur `kimi` (recommandé), puis cliquez sur `Save and Restart` en haut à droite.
|
||||
|
||||
|
||||
|
||||
Ensuite, il suffit de taper `ccr code` dans le terminal pour lancer le flux de travail de codage de Claude Code via Claude Code Router.
|
||||
|
||||
|
||||
|
||||
:::
|
||||
|
||||
#### Utilisations avancées de Claude Code
|
||||
|
||||
Beaucoup de gens utilisent Claude Code au départ comme un simple outil de conversation. Mais en réalité, il intègre de nombreuses fonctionnalités riches qui rendent votre utilisation plus efficace et flexible. Voici quelques commandes et exemples d'utilisation courants :
|
||||
|
||||
Documentation de référence :
|
||||
|
||||
<https://docs.claude.com/en/docs/claude-code/cli-reference>
|
||||
<https://docs.claude.com/en/docs/claude-code/slash-commands>
|
||||
|
||||
| Commande | Fonction | Exemple |
|
||||
| ----------------- | ----------------------------------------- | ---------------------------------------- |
|
||||
| claude | Lancer le mode interactif | `claude` |
|
||||
| claude "query" | Exécuter une tâche ponctuelle et afficher le résultat | `claude "explain this project"` |
|
||||
| claude -p "query" | Exécuter une question ponctuelle et quitter automatiquement après | `claude -p "explain this function xxxx"` |
|
||||
| claude -c | Reprendre la dernière session | `claude -c` |
|
||||
| claude -r | Restaurer la session précédente | `claude -r` |
|
||||
| /resume | Revenir à la session précédente dans le chat en cours | `claude -c`, `/resume` |
|
||||
| /plugin | Gérer les plugins, installer des extensions de commit et review | `/plugin` |
|
||||
| /init | Initialiser la description du projet avec CLAUDE.md | `/init` |
|
||||
| /clear | Effacer le contexte de la session actuelle pour éviter la surcharge | `/clear` |
|
||||
| /compact | Compresser l'historique de conversation pour réduire les tokens de contexte | `/compact` |
|
||||
| /cost | Afficher la consommation actuelle | `/cost` |
|
||||
| /model | Changer le modèle utilisé (ignorable avec une API compatible) | `/model` |
|
||||
| /memory | Gérer les fichiers mémoire CLAUDE.md | |
|
||||
| /help | Afficher la liste des commandes disponibles | `/help` |
|
||||
| exit ou Ctrl+C | Quitter Claude Code | `exit` ou `Ctrl+C` |
|
||||
| /agents | Fonctionnalité avancée, détaillée plus loin | |
|
||||
| /mcp | Fonctionnalité avancée, détaillée plus loin | |
|
||||
|
||||
**CLAUDE.md**
|
||||
|
||||
Référence : <https://www.anthropic.com/engineering/claude-code-best-practices>
|
||||
|
||||
`CLAUDE.md` est un fichier spécial que Claude lit automatiquement et intègre au contexte au début de chaque conversation. Il est donc parfaitement adapté pour y consigner :
|
||||
|
||||
- Les commandes bash courantes
|
||||
- Les fichiers clés et fonctions utilitaires
|
||||
- Les conventions de style de code
|
||||
- Les méthodes de test
|
||||
- Les règles de collaboration du dépôt (par exemple le nommage des branches, merge ou rebase)
|
||||
- La configuration de l'environnement de développement (par exemple l'utilisation de pyenv, le compilateur recommandé)
|
||||
- Les comportements ou pièges spécifiques au projet à surveiller
|
||||
- Toute information que vous souhaitez que Claude « retienne »
|
||||
|
||||
`CLAUDE.md` n'a pas de format imposé, il suffit qu'il soit concis et lisible pour les humains. Par exemple :
|
||||
|
||||
```
|
||||
# Bash commands
|
||||
- npm run build: Build the project
|
||||
- npm run typecheck: Run the typechecker
|
||||
|
||||
# Code style
|
||||
- Use ES modules (import/export) syntax, not CommonJS (require)
|
||||
- Destructure imports when possible (eg. import { foo } from 'bar')
|
||||
|
||||
# Workflow
|
||||
- Be sure to typecheck when you're done making a series of code changes
|
||||
- Prefer running single tests, and not the whole test suite, for performance
|
||||
```
|
||||
|
||||
#### Fonctionnement interne de Claude Code
|
||||
|
||||
Référence : <https://github.com/shareAI-lab/analysis_claude_code>
|
||||
|
||||
Si vous vous demandez pourquoi Claude Code est souvent plus performant que des outils de programmation Agent comme Trae ou Cursor, regardons brièvement son mécanisme de fonctionnement interne.
|
||||
|
||||
Les autres outils de programmation IA en CLI fonctionnent de manière globalement similaire.
|
||||
|
||||
|
||||
|
||||
Claude Code décompose les tâches de programmation en un cycle continu de « perception -- réflexion -- action -- validation », au sein duquel il appelle différents outils pour accomplir les tâches. Il imite le flux de travail d'un développeur humain : écrire du code, l'exécuter, observer les résultats, puis améliorer. Le système fonctionne via une boucle de tâche principale qui exécute les étapes en continu ; à chaque cycle, Claude peut appeler différents outils -- lecture/écriture de fichiers, exécution de commandes, recherche de code, etc. -- puis décider de la prochaine action en fonction des résultats réels renvoyés par ces outils.
|
||||
|
||||
Plusieurs caractéristiques clés méritent d'être notées :
|
||||
|
||||
- **Traitement en flux (Stream Processing)** : Claude peut produire des résultats tout en réfléchissant, sans devoir attendre que tout le code soit écrit avant de l'exécuter.
|
||||
- **Compression intelligente (Intelligent Compression)** : les conversations longs tendent à allonger excessivement le contexte. Claude compresse l'historique en informations clés pour réduire la probabilité d'« oubli », et garantit un fonctionnement efficace en distinguant la mémoire à court et à long terme.
|
||||
- **Contrôle de concurrence (Concurrency Control)** : la conception interne parallèle permet à plusieurs tâches de s'exécuter simultanément sans se gêner mutuellement.
|
||||
- **Gestion de sous-agents (Sub-agent Management)** : en pratique, un seul « rôle » ne traite pas tout. Vous pouvez gérer plusieurs sous-agents collaborant sur le code, chacun responsable de tâches différentes, par exemple l'un dédié aux tests, l'autre à la rédaction de documentation.
|
||||
|
||||
### Codex
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Comme Claude Code, Codex est un outil collaboratif de programmation IA développé par OpenAI. Vous pouvez le considérer comme la « version OpenAI de Claude Code ». Son plus grand avantage est son optimisation poussée pour GPT-5.
|
||||
|
||||
En pratique, GPT-5 offre actuellement une vitesse de réponse plus rapide et un taux d'erreur plus faible (probabilité plus élevée de mener à bien correctement les tâches complexes en plusieurs tours). Son inconvénient est que ses explications ont tendance à être « académiques » et « techniques », parfois trop rigoureuses et riches en informations, ce qui peut être légèrement difficile d'accès pour les débutants.
|
||||
|
||||
Vous pouvez installer Codex avec la commande suivante :
|
||||
|
||||
```
|
||||
npm i -g @openai/codex
|
||||
```
|
||||
|
||||
#### Utiliser l'API officielle OpenAI comme backend
|
||||
|
||||
Si vous utilisez directement l'entrée officielle OpenAI de Codex, la configuration est très simple : une fois que vous avez souscrit à l'abonnement OpenAI ou obtenu le quota d'API correspondant, il suffit de taper `codex` dans la ligne de commande pour lancer le programme et suivre les instructions pour vous connecter.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Utiliser une API OpenAI relayée comme backend
|
||||
|
||||
L'API OpenAI officielle pouvant être coûteuse et soumise à des exigences réseau strictes, nous pouvons également passer par d'autres services de passerelle API pour relayer les appels et contourner ces limitations.
|
||||
|
||||
Avec cette méthode, il suffit d'acheter le quota Codex API correspondant sur une plateforme de relais tierce pour obtenir une expérience proche du Codex OpenAI natif.
|
||||
|
||||
Référence : <https://open-dev.feishu.cn/wiki/PAqUwWG4IiuwTvkQ2sGcaQuPnXc>
|
||||
Page de recharge : <https://api.zyai.online/account/topup/recharge>
|
||||
|
||||
Notez qu'une fois le token obtenu, vous devez configurer la clé API localement.
|
||||
|
||||
Dans les paramètres du groupe de clés, assurez-vous de sélectionner l'élément spécialement dédié à Codex.
|
||||
|
||||
|
||||
|
||||
Ensuite, vous devez insérer la clé obtenue dans l'invite suivante, et confier l'intégralité du prompt à Trae pour qu'il vous aide à compléter le processus de configuration :
|
||||
|
||||
````bash
|
||||
My API key is: [Paste your obtained sk-xxxxx key here]
|
||||
|
||||
Please help me complete the following configuration tasks:
|
||||
|
||||
1. Create configuration directory
|
||||
- Create a `.codex` folder under my user directory
|
||||
- Windows path should be: `C:\Users\[My Username]\.codex`
|
||||
2. Backup existing configuration (if exists)
|
||||
- Check if `.codex\config.toml` exists
|
||||
- If it exists, rename it to `config.toml.bak.[current timestamp]` (timestamp format: yyyyMMddHHmmss)
|
||||
3. Create configuration file
|
||||
- Create `config.toml` in the `.codex` directory
|
||||
- Write the following complete content:
|
||||
```toml
|
||||
preferred_auth_method = "apikey"
|
||||
|
||||
[model_providers.myrelay]
|
||||
name = "My Relay Station"
|
||||
base_url = "https://api.zyai.online/v1"
|
||||
env_key = "MYRELAY_API_KEY"
|
||||
wire_api = "responses"
|
||||
request_max_retries = 4
|
||||
stream_max_retries = 10
|
||||
stream_idle_timeout_ms = 300000
|
||||
|
||||
[profiles.myrelay]
|
||||
model_provider = "myrelay"
|
||||
model = "gpt-5"
|
||||
model_reasoning_effort = "medium"
|
||||
|
||||
[tools]
|
||||
web_search = true
|
||||
|
||||
4. Set system environment variable
|
||||
Variable name: MYRELAY_API_KEY
|
||||
Variable value: The key I gave you
|
||||
|
||||
5. Confirm completion and report back:
|
||||
|
||||
The full path of the configuration file
|
||||
Whether the environment variable was set successfully
|
||||
I can use the command `codex --profile myrelay` to run it
|
||||
````
|
||||
|
||||
Une fois la configuration terminée, vous pouvez lancer Codex avec l'API relayée via `codex --profile myrelay`. L'utilisation est ensuite similaire à Claude Code : il suffit de saisir vos idées et besoins dans la boîte de dialogue.
|
||||
|
||||
### OpenCode
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
OpenCode est une plateforme open source d'agents de codage IA destinée aux développeurs, positionnée comme un « Claude Code multi-modèles ». Son interface d'interaction principale est le Terminal, et elle prend également en charge l'intégration d'éditeurs (VS Code, Neovim, etc.), pouvant se connecter en profondeur aux dépôts de code locaux et accomplir un flux de développement complet, de la compréhension du code à l'exécution d'ingénierie, via le langage naturel.
|
||||
|
||||
Ce n'est pas un outil de programmation IA lié à un seul modèle, mais une plateforme ouverte d'agents de codage IA permettant de passer librement de GPT à Claude, Gemini ou même des modèles locaux. Même OpenAI prend officiellement en charge la connexion d'OpenCode à Codex / abonnements OpenAI.
|
||||
|
||||
|
||||
|
||||
Vous pouvez installer OpenCode avec la commande suivante :
|
||||
|
||||
```bash
|
||||
# Linux / Unix
|
||||
curl -fsSL https://opencode.ai/install | bash
|
||||
|
||||
# Windows
|
||||
npm i -g opencode-ai
|
||||
```
|
||||
|
||||
#### Utiliser les modèles gratuits dans OpenCode
|
||||
|
||||
OpenCode propose périodiquement des modèles gratuits utilisables, dont la configuration est très simple. Dans le répertoire où vous souhaitez utiliser OpenCode, lancez le programme en tapant `opencode` dans la ligne de commande pour accéder au panneau de chat. Saisissez la commande `/models` et recherchez le mot-clé « free » pour voir les modèles gratuits signalés par le mot « free ».
|
||||
|
||||
|
||||
|
||||
En général, les modèles gratuits accomplissent les tâches de codage plus lentement que les modèles payants ou sur abonnement. Cela dépend généralement de la congestion du routage du modèle, de la période de pointe de codage et des capacités propres au modèle.
|
||||
|
||||
#### Utiliser un modèle tiers comme modèle de codage principal dans OpenCode
|
||||
|
||||
C'est l'avantage central d'OpenCode : il permet de changer librement de modèle tout en conservant les mêmes MCP, Skills et contexte pour accomplir différentes tâches de codage. L'exemple ci-dessous montre comment connecter GPT-5.3 Codex d'OpenAI à OpenCode comme modèle de codage principal.
|
||||
|
||||
Dans la fenêtre de chat d'OpenCode, saisissez la commande `/connect`, sélectionnez la première instruction la plus pertinente et appuyez sur Entrée pour accéder à l'authentification d'un fournisseur de modèles tiers.
|
||||
|
||||
|
||||
|
||||
Ici, nous choisissons OpenAI comme exemple, appuyez sur Entrée pour sélectionner la méthode d'authentification.
|
||||
|
||||
|
||||
|
||||
Choisissez celle que vous préférez, seule la méthode d'authentification diffère. Ici, nous sélectionnons la première option pour une connexion par navigateur.
|
||||
|
||||
|
||||
|
||||
Copiez ce lien dans votre navigateur et procédez à une connexion OpenAI normale. Lorsque le navigateur affiche « Authorization Successful », le client OpenCode basculera automatiquement vers l'interface de sélection du modèle OpenAI.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Installer le plugin Oh My OpenAgent
|
||||
|
||||
La force d'OpenCode réside également dans son écosystème communautaire très actif. Vous pouvez trouver de nombreux plugins liés à OpenCode sur Github. Si OpenCode est un outil collaboratif IA permettant de changer librement de modèle, alors Oh-My-OpenAgent est un « système de commandement multi-agents de programmation IA » fonctionnant au-dessus d'OpenCode. Il peut décomposer une tâche complexe en sous-tâches confiées à différents modèles, chacun travaillant dans son domaine de compétence.
|
||||
|
||||
|
||||
|
||||
Vous pouvez copier l'instruction suivante et la coller dans le modèle configuré précédemment dans OpenCode pour installer le plugin.
|
||||
|
||||
```text
|
||||
Install and configure oh-my-openagent by following the instructions here:
|
||||
https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md
|
||||
```
|
||||
|
||||
Voici les fonctionnalités et la description des capacités d'Oh-My-OpenAgent.
|
||||
|
||||
| Fonctionnalité | Description |
|
||||
| :-------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| **Légion autonome (Discipline Agents)** | Sisyphus coordonne Hephaestus, Oracle, Librarian et Explorer. Une équipe complète de développement IA travaillant en parallèle. |
|
||||
| **Team Mode** (v4.0, activation optionnelle) | Agent leader + jusqu'à 8 membres parallèles, visualisation tmux en temps réel, famille d'outils `team_*` dédiée. pilote `hyperplan` (5 relecteurs antagonistes) et `security-research` (3 chasseurs + 2 ingénieurs PoC).[Documentation →](docs/guide/team-mode.md) |
|
||||
| **`ultrawork` / `ulw`** | Déclenchement en un clic, tous les agents se déploient. La tâche ne s'arrête pas tant qu'elle n'est pas terminée. |
|
||||
| **[IntentGate Porte d'intention](https://factory.ai/news/terminal-bench)** | Avant toute action réelle, analyse la véritable intention de l'utilisateur. Fini les réponses IA déclenchées à tort par un sens littéral. |
|
||||
| **Outil d'édition basé sur le hachage** | Chaque modification est vérifiée par le hachage du contenu `LINE#ID`, 0% de modifications erronées. Inspiré par [oh-my-pi](https://github.com/can1357/oh-my-pi). [The Harness Problem →](https://blog.can.ac/2026/02/12/the-harness-problem/) |
|
||||
| **LSP + AST-Grep** | Renommage au niveau workspace, diagnostics pré-build, réécriture basée sur AST. Offre aux agents une précision de niveau IDE. |
|
||||
| **Agents en arrière-plan** | Lancement simultané de 5+ experts travaillant en parallèle. Maintient un contexte propre, résultats disponibles à tout moment. |
|
||||
| **MCP intégré** | Exa (recherche web), Context7 (documentation officielle), Grep.app (recherche de code source GitHub). Activé par défaut. |
|
||||
| **Ralph Loop / `/ulw-loop`** | Boucle auto-référentielle. N'accepte jamais un taux de complétion inférieur à 100%. |
|
||||
| **Exécution Todo forcée** | L'agent veut s'économiser ? Le système le rappelle à l'ordre. Vos tâches doivent être terminées. |
|
||||
| **Vérificateur de commentaires** | Élimine les commentaires redondants au goût trop prononcé d'IA. Le code produit ressemble à celui d'un ingénieur senior chevronné. |
|
||||
| **Intégration Tmux** | Support complet de terminal interactif. Exécuter des REPL, utiliser un débogueur, des outils TUI, le tout en session temps réel. |
|
||||
| **Compatibilité Claude Code** | Vos Hooks, commandes, skills, MCP et plugins existants ? Tous migrables sans effort. |
|
||||
| **MCP intégré aux Skills** | Les skills embarquent automatiquement les serveurs MCP nécessaires. Activation à la demande, sans saturer votre fenêtre de contexte. |
|
||||
| **Planificateur Prometheus** | Avant d'écrire la moindre ligne de code, élabore un plan stratégique via un mode entretien. |
|
||||
| **`/init-deep`** | Génère automatiquement des `AGENTS.md` à tous les niveaux du répertoire projet. Économise des tokens et améliore considérablement la compréhension de l'agent. |
|
||||
|
||||
Sisyphus (claude-opus-4-7 / kimi-k2.6 / glm-5.1) est votre commandant en chef. Il est responsable de la planification, de l'allocation des tâches à l'équipe d'experts, et pousse les tâches à leur terme avec une stratégie de parallélisme extrêmement agressif. Il n'abandonne jamais en cours de route.
|
||||
|
||||
Hephaestus (gpt-5.5) est votre travailleur en profondeur autonome. Vous lui donnez uniquement un objectif, pas la méthode. Il explore automatiquement les patterns du dépôt de code, exécute les tâches de bout en bout de manière indépendante, sans jamais vous demander d'assistance. Un véritable artisan.
|
||||
|
||||
Prometheus (claude-opus-4-7 / kimi-k2.6 / glm-5.1) est votre stratège. Il délimite le périmètre et construit un plan d'exécution détaillé via un mode entretien, avant d'écrire la moindre ligne de code.
|
||||
|
||||
Une fois ces éléments compris, vous pouvez utiliser OpenCode équipé du plugin Oh-My-OpenAgent pour accomplir vos tâches de codage.
|
||||
|
||||
## Autres usages des outils de programmation IA en CLI
|
||||
|
||||
### Écrire un cahier des charges avec l'IA : apprendre à « concrétiser les besoins »
|
||||
|
||||
Pour les grands modèles de langage, les besoins abstraits doivent être « concrétisés ». Par exemple : « j'ai faim » est un besoin abstrit. Nous devons le transformer en : « j'ai un peu faim, je pourrais manger un pain aux haricots rouges avec un verre de lait de soja. » -- Voilà un besoin concret et exécutable.
|
||||
|
||||
Mais transformer un besoin abstrait en besoin concret est un processus qui demande beaucoup d'énergie. Si nous n'avons pas vu suffisamment d'exemples, il est difficile d'imaginer rapidement comment décomposer un problème abstrait en modules détaillés. Dans ce cas, la meilleure approche est de laisser l'IA réaliser l'étape de « concrétisation » pour vous.
|
||||
|
||||
Par exemple, si je veux développer une application de « planning quotidien », l'idée la plus simple pourrait être :
|
||||
|
||||
`Please help me write a daily planning app where I can write my plans each day and get reminders.`
|
||||
|
||||
L'IA peut certes décomposer la tâche directement sur cette base, puis procéder étape par étape, mais des erreurs ou des malentendus sont possibles en cours de route. Pour réduire les risques, nous pouvons demander à l'IA de développer d'abord le besoin :
|
||||
|
||||
`Based on my needs, please elaborate and provide a more detailed Product Requirement Document for reference. My idea is: Please help me write a daily planner app that supports daily plan-writing and provides reminders .`
|
||||
|
||||
L'IA pourrait alors produire un PRD complet tel que celui-ci :
|
||||
|
||||
```
|
||||
Product Requirements Document (PRD): "Today's Plan" App
|
||||
Document Version: 1.0
|
||||
Creation Date: October 27, 2023
|
||||
Author: (Your Name/Product Manager)
|
||||
|
||||
1. Product Introduction
|
||||
1.1 Product Name
|
||||
Today's Plan
|
||||
1.2 Product Vision
|
||||
"Today's Plan" is a minimalist and highly efficient daily planning and reminder tool, dedicated to helping users eliminate procrastination and forgetfulness, plan every day clearly, and ensure tasks are carried out through an intelligent reminder system--ultimately enabling users to gain a stronger sense of control and achievement over their time.
|
||||
1.3 Target Users (User Personas)
|
||||
We mainly serve three types of users:
|
||||
Students (Xiao Ming):
|
||||
Characteristics: Multiple tasks such as courses, assignments, club activities, exam prep, needing organized time arrangement.
|
||||
Pain Points: Easily forget small tasks or assignment deadlines; feel overwhelmed switching between tasks; want to build regular study and life habits.
|
||||
Needs: A simple tool to list daily to-dos and provide reminders before class/self-study.
|
||||
Office Workers (Zhang Wei):
|
||||
Characteristics: Fast-paced work, many meetings, reports, project milestones, and personal affairs (fitness, picking up children).
|
||||
Pain Points: Easily forget important meetings or work milestones; get interrupted by urgent tasks and forget the original plan; feel busy but inefficient at end of day.
|
||||
Needs: Need a tool to quickly record and schedule daily work and send strong reminders at key times (e.g., 15 minutes before meetings).
|
||||
Freelancers/Self-disciplined Seekers (Li Na):
|
||||
Characteristics: High freedom of time, but strong self-management required for work output and personal growth.
|
||||
Pain Points: Easily procrastinate, lack external supervision; start the day without a clear plan, leading to low time utilization.
|
||||
Needs: Need a tool to help build a daily fixed routine (Morning Routine) and review daily achievements for positive feedback.
|
||||
|
||||
2. User Stories
|
||||
As a user, I want to quickly create today's plan list so I have an overview of all my tasks for the day.
|
||||
As a user, I want to set specific start and end times for each task so I can create a visual timeline.
|
||||
As a user, I want to receive push notification reminders before a task starts so I won't miss any important arrangements.
|
||||
As a user, I want to customize the reminder time (such as 5, 15, or 60 minutes in advance) so reminders better fit my habits.
|
||||
As a user, I want to easily mark completed tasks so I can feel accomplished and clearly see my progress.
|
||||
As a user, I want to see a summary of my completed plans at the end of each day for reviewing and self-motivation.
|
||||
As a user, I want to conveniently edit and delete tasks to handle last-minute changes.
|
||||
As a user, I want to view plans and achievements from previous days to review my efficiency and habits.
|
||||
|
||||
3. Feature Breakdown
|
||||
Core Features (MVP - Minimum Viable Product)
|
||||
Module 1: Plan Management
|
||||
3.1.1 Daily Plan Homepage
|
||||
Interface: "Today" as the core view, current date shown at the top.
|
||||
View: Timeline list, clearly showing tasks scheduled from morning to evening. Tasks without a time can be listed in the top or bottom "To-do List" section.
|
||||
Interactions:
|
||||
Click the "+" button in the bottom right to quickly create a new task.
|
||||
Pull down to refresh the page.
|
||||
Swipe left/right to view yesterday's and tomorrow's plans.
|
||||
3.1.2 Create/Edit Task
|
||||
Entry: Click "+" on the homepage or a time slot in the list.
|
||||
Fields:
|
||||
Task title (required): Briefly describe the task, e.g., "10 AM Weekly Product Meeting."
|
||||
Task time (optional):
|
||||
Set "start time" and "end time."
|
||||
Provide "all-day" option for unspecified time tasks.
|
||||
Default time picker should be quick and convenient.
|
||||
Reminder setting (required, with default value): See Module 2.
|
||||
Notes (optional): Add further descriptions, links, or location info.
|
||||
Actions: Save, cancel, delete task.
|
||||
3.1.3 Task Interaction
|
||||
Mark as complete: Checkbox before each task; checking adds a strikethrough and gray background, indicating completion. Can unmark if needed.
|
||||
Edit task: Click the task itself to enter edit page.
|
||||
Delete task: Swipe left on a task to reveal "Delete" button.
|
||||
Module 2: Smart Reminder System
|
||||
3.2.1 Reminder Trigger
|
||||
Mechanism: Based on task's set "start time" and the user's "reminder lead time," send a push notification from device.
|
||||
Offline Support: Locally scheduled reminders must trigger even if user is offline.
|
||||
3.2.2 Reminder Content & Format
|
||||
Notification title: App name "Today's Plan."
|
||||
Body: "Reminder: [Task Title] will start at [Start Time]." E.g., "Reminder: Product Meeting will start at 10:00."
|
||||
Sound: Use system default or offer several simple, effective tones.
|
||||
3.2.3 Reminder Settings
|
||||
Global Settings (in Settings page):
|
||||
User can set a default reminder time, e.g., "15 minutes before task starts." New tasks adopt this by default.
|
||||
Single Task Settings (in create/edit page):
|
||||
Users can override global settings for important tasks, choosing specific reminder times like "on time," "5 minutes early," "30 minutes early," or "1 hour early."
|
||||
Provide "no reminder" option.
|
||||
Subsequent Features (V1.1, V2.0)
|
||||
3.3 Daily Review & Statistics
|
||||
Push a summary notification at a set time every night (e.g., 22:00): "How was your day? Take a look at your achievements!"
|
||||
Generate a simple daily report card: shows total planned tasks, completed tasks, completion rate, plus an encouraging message.
|
||||
3.4 History Review
|
||||
Calendar view to click on any past day and check its plans and completion status. Days with high completion rates marked with a special color.
|
||||
3.5 Templates
|
||||
Allow users to save a successful daily plan as a template, e.g., "Efficient Workday," "Relaxing Weekend."
|
||||
When creating tomorrow's plan, one-click import a template, modify slightly to save time.
|
||||
3.6 Themes & Personalization
|
||||
Offer dark mode.
|
||||
Allow changing several primary color themes.
|
||||
|
||||
4. Non-Functional Requirements
|
||||
4.1 Performance
|
||||
Response: App launch time under 2 seconds; adding/editing tasks must be smooth and lag-free.
|
||||
Resource Use: Low battery and memory consumption in background; do not over-consume resources waiting for reminders.
|
||||
4.2 Usability
|
||||
Minimal & intuitive: UI must be minimal, primary functions accessible within 3 clicks. No tutorial needed for new users.
|
||||
Error tolerance: Offer undo (e.g. brief undo after mistakenly deleting a task).
|
||||
4.3 Reliability
|
||||
Reliable reminders: Reminder function is the product's lifeline; must guarantee 99.99% timely and accurate delivery.
|
||||
Data loss-free: User plans must be reliably stored locally. Future versions can support cloud sync to prevent data loss on device change.
|
||||
4.4 Compatibility
|
||||
Platform: Support major iOS and Android versions (latest 3-4 releases).
|
||||
Screen: Layout must fit various phone screen sizes.
|
||||
|
||||
5. Roadmap
|
||||
V1.0 (MVP):
|
||||
Goal: Validate core value--planning & reminders.
|
||||
Features: Complete all "Core Features" described above (Plan management, smart reminders).
|
||||
V1.1 (Quick Optimization):
|
||||
Goal: Improve retention and achievement.
|
||||
Features: Add "Daily Review & Statistics," "History Review."
|
||||
V2.0 (Enhanced Experience):
|
||||
Goal: Increase efficiency and personalization.
|
||||
Features: Add "Templates," "Themes & Personalization," and start developing "Cloud Sync."
|
||||
```
|
||||
|
||||
Comparé à notre phrase initiale « aide-moi à écrire une application de planification quotidienne avec des rappels », ce document est désormais beaucoup plus détaillé. Vous pouvez modifier son contenu selon vos besoins réels, en ajoutant ou supprimant des éléments ; pour les modules dont vous n'êtes pas sûr, vous pouvez aussi continuer à demander à l'IA de proposer d'autres alternatives, puis sélectionner et fusionner pour obtenir la version finale.
|
||||
|
||||
De cette manière, nous pouvons facilement transformer des idées abstraites en descriptions concrètes. Pour le développement IA, « concret » égale productivité : plus les besoins sont précis, plus il est facile d'obtenir un projet stable et de haute qualité. Vous pouvez essayer de reprendre un de vos petits projets précédents avec cette méthode et comparer la différence.
|
||||
|
||||
Si vous trouvez ce type de « prompt de besoins » trop long, une approche naturelle consiste à l'écrire dans un document markdown séparé, comme votre « document de besoins / document de développement / PRD ». Ensuite, chaque fois que vous demandez à l'IA de développer un projet, il suffit de lui demander de « se référer à ce document » au lieu de retaper un long prompt à chaque fois. Vous pouvez également améliorer ce document au fil des itérations, pour que les projets ultérieurs en bénéficient directement.
|
||||
|
||||
Voici quelques autres scénarios d'utilisation courants :
|
||||
|
||||
### Gérer les dossiers
|
||||
|
||||
Vous pouvez essayer d'utiliser les outils de programmation IA en CLI pour gérer les fichiers dans le dossier courant. Par exemple, si vous avez un ensemble de fichiers en désordre et que vous souhaitez les trier et les classer, vous pouvez dire à Claude Code ou Codex :
|
||||
|
||||
`Please help me organize the contents of the current folder. I want to group files with the same content together & I want to group files from the same time period together. Please help me handle this.`
|
||||
|
||||
### Développer un nouveau projet
|
||||
|
||||
C'est presque identique à ce que nous faisions précédemment avec z.ai ou Trae -- nous pouvons aussi utiliser directement les outils de programmation IA en CLI pour développer de nouveaux projets à partir de zéro. Bien sûr, il est préférable de préparer un cahier des charges à l'avance.
|
||||
|
||||
Plus le document de besoins est détaillé, meilleur sera le résultat final. Vous pouvez affiner le document en plusieurs itérations en fonction de vos idées évolutives ; plus le document est complet, plus l'implémentation du code sera stable et mature.
|
||||
|
||||
### Déployer des projets open source (par exemple Dify)
|
||||
|
||||
Pour les étudiants débutants en informatique, déployer un projet open source depuis GitHub est souvent difficile. Mais nous pouvons parfaitement confier cette tâche à Claude Code, comme nous l'avons fait dans le tutoriel Dify :
|
||||
|
||||
<https://github.com/langgenius/dify>
|
||||
|
||||
Si je veux faire tourner mon propre Dify localement, il me suffit de donner ce lien à Claude Code, puis de saisir :
|
||||
|
||||
`I want to deploy this GitHub project ``https://github.com/langgenius/dify`` . Please help me clone the project and run it.`
|
||||
|
||||
Après avoir reçu votre demande, Claude Code effectuera automatiquement une série d'opérations, dont le clonage du code depuis GitHub, la configuration de l'environnement d'exécution, le lancement du projet, etc. Si une étape échoue ou si le projet ne se lance pas correctement, vous n'aurez qu'à procéder à quelques ajustements manuels selon les indications. Outre Dify, vous pouvez aussi utiliser Claude Code pour déployer la plupart des projets open source courants sur GitHub -- il vous suffit d'une boîte de dialogue et du temps d'un café.
|
||||
|
||||
|
||||
|
||||
### Expliquer du code et rédiger de la documentation
|
||||
|
||||
Pour certains projets complexes, ou les grands projets générés automatiquement par l'IA, vous trouverez peut-être le code trop long et la logique trop complexe pour être facilement compréhensible. C'est le moment de demander aux outils de programmation IA en CLI de vous aider à « lire le code ». Vous pouvez poser des questions comme :
|
||||
|
||||
- Expliquez-moi ce projet : comment le lancer, comment l'utiliser, comment le modifier et poursuivre le développement ?
|
||||
- Décrivez-moi le flux global du projet : comment le programme fonctionne-t-il ? Quelles opérations l'utilisateur peut-il effectuer dans l'interface ?
|
||||
- Rédigez-moi une documentation complète pour ce projet, incluant la documentation de développement et la documentation d'exécution.
|
||||
- Sur la base de tout le contenu du dossier courant, rédigez une description détaillée et enregistrez-la dans un document markdown spécifié.
|
||||
|
||||
### D'autres possibilités
|
||||
|
||||
Bien sûr, les outils de programmation IA en CLI peuvent faire bien plus que ce qui précède. Ne les considérez pas seulement comme des « outils de code », mais plutôt comme des agents intelligents capables d'agir de manière autonome. Vous pouvez leur demander de :
|
||||
|
||||
- Gérer et organiser vos fichiers locaux ;
|
||||
- Tenir un journal, rédiger des bilans ;
|
||||
- Analyser et corriger des erreurs système ;
|
||||
- Exécuter diverses tâches répétitives en ligne de commande, etc.
|
||||
|
||||
Peut-être que dans un avenir proche, ils deviendront le partenaire IA le plus important et celui qui vous comprend le mieux sur votre ordinateur.
|
||||
@@ -0,0 +1,907 @@
|
||||
# Comment intégrer Stripe et d'autres systèmes de paiement
|
||||
|
||||
Lorsque votre produit dispose déjà de pages, d'un système de connexion, d'une base de données et d'un backend fonctionnel, la question suivante est : **comment facturer**.
|
||||
|
||||
Beaucoup de personnes qui intègrent un paiement pour la première fois concentrent toute leur attention sur « comment rediriger vers la page de paiement ». Mais ce qui détermine vraiment la stabilité du système, ce n'est pas le bouton, c'est l'ensemble de la chaîne de facturation : qui décide du prix, qui confirme le succès du paiement, qui met à jour la base de données, qui gère les droits d'accès.
|
||||
|
||||
Cet article est divisé en deux parties :
|
||||
|
||||
- **La première partie** se concentre uniquement sur l'intégration de base la plus pratique, avec pour objectif de vous permettre d'intégrer Stripe à votre projet le plus rapidement possible.
|
||||
- **La seconde partie** est regroupée en annexe et couvre les détails des Webhooks, les événements d'abonnement, et les différences de solutions de paiement selon les pays et régions.
|
||||
|
||||
> 💡 Il est recommandé d'avoir terminé ces chapitres avant de continuer
|
||||
>
|
||||
> - [De la base de données à Supabase](../database-supabase/)
|
||||
> - [Grands modèles pour écrire du code d'interface et de la documentation d'API](../ai-interface-code/)
|
||||
> - [Comment déployer une application Web](../zeabur-deployment/)
|
||||
|
||||
# Ce que vous allez apprendre
|
||||
|
||||
1. À quoi ressemble un système de paiement minimum viable.
|
||||
2. Comment intégrer Stripe dans votre projet de la manière la plus rapide.
|
||||
3. Comment rédiger des prompts pour que l'IA ajoute directement un système de paiement.
|
||||
4. Si vous ne faites pas un projet Stripe à l'international, quelle solution de paiement privilégier selon les régions.
|
||||
|
||||
---
|
||||
|
||||
# Première partie : prise en main
|
||||
|
||||
## 1. Retenez d'abord ces 3 principes
|
||||
|
||||
Si vous ne deviez retenir que trois choses, voici lesquelles :
|
||||
|
||||
1. **Le prix doit être décidé par le backend**, vous ne pouvez pas faire confiance au montant envoyé par le frontend.
|
||||
2. **Ce qui active réellement les droits, c'est le Webhook**, pas la page `success`.
|
||||
3. **Votre propre base de données doit conserver l'état du paiement**, vous ne pouvez pas dépendre uniquement du tableau de bord Stripe.
|
||||
|
||||
Ces trois principes constituent les limites essentielles d'un système de paiement. Tant que ces limites sont respectées, que vous passiez ensuite à Stripe, PayPal, Alipay ou WeChat Pay, il s'agit au fond uniquement d'un « changement d'interface, l'architecture reste la même ».
|
||||
|
||||
## 2. Que se passe-t-il si, au lieu de traiter côté backend, on connecte Stripe directement depuis le frontend ?
|
||||
|
||||
C'est l'idée la plus naturelle pour beaucoup de personnes qui font leur premier paiement :
|
||||
|
||||
- Il y a déjà un bouton « Acheter » sur la page
|
||||
- Ne pourrais-je pas laisser le frontend se connecter directement à Stripe
|
||||
- Ainsi, pas besoin de backend
|
||||
|
||||
Si vous faites simplement une fausse page de démonstration, cette approche ne pose évidemment aucun problème.
|
||||
Mais si vous comptez vraiment encaisser de l'argent, **cette voie mène généralement à des problèmes sérieux**.
|
||||
|
||||
Les problèmes les plus courants sont les suivants :
|
||||
|
||||
1. **Le prix est facilement modifiable**
|
||||
Les requêtes dans le navigateur sont envoyées depuis l'ordinateur de l'utilisateur. N'importe qui peut modifier le contenu de la requête.
|
||||
2. **Exposition facile d'informations sensibles**
|
||||
Les clés secrètes véritablement importantes, la logique de prix et la logique d'activation des abonnements ne doivent jamais se trouver côté frontend.
|
||||
3. **Impossible de confirmer de manière fiable « ce paiement est-il vraiment un succès »**
|
||||
Le fait que l'utilisateur soit redirigé vers la page de succès ne signifie pas que votre base de données a été correctement synchronisée.
|
||||
4. **La base de données devient incohérente**
|
||||
L'utilisateur peut dire « j'ai bien payé », mais votre propre système n'en a gardé aucune trace.
|
||||
|
||||
Une répartition des rôles plus sûre serait donc :
|
||||
|
||||
- Frontend : afficher les boutons, initier l'achat, rediriger les pages
|
||||
- Backend : décider des prix, créer les sessions de paiement, recevoir les Webhooks, mettre à jour la base de données
|
||||
|
||||
::: info Vous pouvez résumer cette section en une seule phrase
|
||||
**Le frontend peut gérer la redirection, mais le backend doit gérer la tarification et la confirmation.**
|
||||
|
||||
Dès qu'il s'agit de vrais encaissements, ne confiez jamais au frontend « le pouvoir ultime de décider du prix » ni « la logique d'activation après un paiement réussi ».
|
||||
:::
|
||||
|
||||
## 3. Quand est-il judicieux de commencer par Stripe ?
|
||||
|
||||
Si vous travaillez sur les scénarios suivants, Stripe est souvent le point de départ le plus naturel :
|
||||
|
||||
- Un SaaS destiné aux utilisateurs internationaux
|
||||
- Un produit par abonnement
|
||||
- Des produits numériques, des templates, des packs de crédits IA
|
||||
- Vous souhaitez valider rapidement la monétisation, plutôt que de gérer d'emblée trop de détails de paiement locaux
|
||||
|
||||
Si vos utilisateurs principaux se trouvent en Chine continentale, Stripe n'est généralement pas le premier choix -- ce point sera abordé en annexe.
|
||||
|
||||
## 4. La chaîne de paiement minimum viable
|
||||
|
||||
Commençons par la version minimale. Tant que cette chaîne fonctionne, votre système de paiement possède une ossature.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
user["Utilisateur"]
|
||||
frontend["Page frontend"]
|
||||
backend["Votre backend"]
|
||||
checkout["Stripe Checkout"]
|
||||
webhook["Stripe Webhook"]
|
||||
db["Supabase / Base de données métier"]
|
||||
|
||||
user -->|"Clique sur Achat"| frontend
|
||||
frontend -->|"Demande de création de session de paiement"| backend
|
||||
backend -->|"Crée une Session selon le prix backend"| checkout
|
||||
frontend -->|"Redirige vers la page de paiement"| checkout
|
||||
checkout -->|"Envoie un événement après paiement"| webhook
|
||||
webhook -->|"Vérifie la signature et met à jour le statut"| backend
|
||||
backend -->|"Écrit dans orders / subscriptions"| db
|
||||
db -->|"Le frontend lit le dernier statut après actualisation"| frontend
|
||||
```
|
||||
|
||||
Traduit en langage simple :
|
||||
|
||||
1. L'utilisateur clique sur le bouton.
|
||||
2. Le frontend demande au backend un lien de paiement.
|
||||
3. Le backend crée une session de paiement avec la clé Stripe.
|
||||
4. L'utilisateur paie sur la page Stripe.
|
||||
5. Stripe vous notifie que « le paiement a vraiment réussi » via un Webhook.
|
||||
6. Votre backend met ensuite à jour la base de données.
|
||||
|
||||
## 5. Diagramme de séquence standard pour l'initiation d'un paiement
|
||||
|
||||
Si vous préférez regarder un diagramme système plus formel, voici le diagramme de séquence :
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor User as Utilisateur
|
||||
participant Frontend as Page frontend
|
||||
participant Backend as API backend
|
||||
participant Stripe as Stripe Checkout
|
||||
|
||||
User->>Frontend: Clique sur "Passer Premium" ou "Acheter"
|
||||
Frontend->>Backend: POST /api/billing/create-checkout-session
|
||||
Note right of Frontend: Le frontend transmet plan / userId / email\nmais pas le montant final
|
||||
Backend->>Backend: Vérifie le plan et mappe le priceId
|
||||
Backend->>Stripe: Crée une Checkout Session
|
||||
Stripe-->>Backend: Retourne session.url
|
||||
Backend-->>Frontend: Retourne le lien de paiement
|
||||
Frontend-->>User: Redirige vers la page de paiement Stripe
|
||||
User->>Stripe: Effectue le paiement
|
||||
```
|
||||
|
||||
## 6. Démarrage rapide
|
||||
|
||||
Si vous souhaitez l'intégrer le plus rapidement possible dans votre projet, suivez ces 5 étapes.
|
||||
|
||||
### 6.1 Étape 1 : Créer des produits et des prix dans le tableau de bord Stripe
|
||||
|
||||
L'objectif de cette étape n'est pas « de configurer quelques choses au hasard », mais de définir clairement dans Stripe **ce que vous vendez exactement et comment vous prévoyez de facturer**.
|
||||
|
||||
Dans le modèle de Stripe :
|
||||
|
||||
- **Product** représente « ce que vous vendez », par exemple `Abonnement Pro`
|
||||
- **Price** représente « à quel prix vous le vendez et selon quel cycle », par exemple `9,90 USD/mois`, `99 USD/an`
|
||||
|
||||
Pourquoi commencer par cette étape ?
|
||||
Car lorsque votre backend crée ensuite une Checkout Session, il ne transmet pas directement un montant à Stripe, mais un `price_id` déjà existant. Stripe utilise ensuite ce `price_id` pour générer la véritable page de paiement, le montant, la devise et le cycle d'abonnement.
|
||||
|
||||
Si vous sautez cette étape, l'étape « créer un lien de paiement » sera tout simplement impossible.
|
||||
|
||||
::: info Pourquoi faut-il s'arrêter ici
|
||||
Beaucoup de débutants trouvent les termes `Product` et `Price` un peu fastidieux, avec l'impression d'apprendre le jargon interne de Stripe.
|
||||
|
||||
En réalité, cette étape consiste à faire quelque chose de très simple :
|
||||
- Définir clairement « ce qu'on vend »
|
||||
- Définir clairement « à quel prix on le vend »
|
||||
- Permettre au backend d'utiliser ensuite un `price_id` stable pour créer des liens de paiement
|
||||
|
||||
Une fois ce principe compris, les Checkout Sessions ne vous sembleront plus abstraites.
|
||||
:::
|
||||
|
||||
Pour un système d'abonnement minimum viable, vous devez au moins créer ces deux niveaux :
|
||||
|
||||
- un `Product`
|
||||
- un ou plusieurs `Price`
|
||||
|
||||
Vous pouvez ouvrir directement ces pages :
|
||||
|
||||
- Page de connexion Stripe Dashboard : [Dashboard Login](https://dashboard.stripe.com/login)
|
||||
- Documentation Stripe sur la gestion des produits et prix : [Manage products and prices](https://docs.stripe.com/products-prices/manage-prices)
|
||||
- Documentation Stripe de démarrage rapide Checkout : [Build a Stripe-hosted checkout page](https://docs.stripe.com/checkout/quickstart?lang=node)
|
||||
- Page des produits Stripe Dashboard : [Product catalog](https://dashboard.stripe.com/test/products)
|
||||
|
||||
Nous vous recommandons de travailler d'abord en **mode Test**, plutôt que de créer directement en environnement de production.
|
||||
|
||||
La configuration minimale la plus courante est :
|
||||
|
||||
- `Product` : `Pro Plan`
|
||||
- `Price 1` : `pro_monthly`
|
||||
- `Price 2` : `pro_yearly`
|
||||
|
||||
Dans le tableau de bord, vous pouvez comprendre l'ordre comme suit :
|
||||
|
||||
1. Créez d'abord un produit `Pro Plan`
|
||||
2. Puis ajoutez deux prix sous ce produit
|
||||
3. L'abonnement mensuel et l'abonnement annuel sont en réalité deux modes de facturation pour un même produit
|
||||
|
||||
Une fois terminé, vous devez au minimum noter ces informations :
|
||||
|
||||
- Le `price_id` du prix mensuel
|
||||
- Le `price_id` du prix annuel
|
||||
- Vos propres noms de plan, par exemple `pro_monthly`, `pro_yearly`
|
||||
|
||||
Si c'est votre première visite dans le tableau de bord Stripe, nous vous conseillons de considérer cette étape comme suit :
|
||||
|
||||
- `Product` détermine ce qui est vendu sur la page de paiement
|
||||
- `Price` détermine le montant facturé sur la page de paiement
|
||||
- Ce que le backend utilisera réellement par la suite, c'est principalement le `price_id`
|
||||
|
||||
::: info Les valeurs vraiment importantes à retenir
|
||||
Le plus important sur cette page n'est pas le nom du produit, mais le `price_id`.
|
||||
|
||||
Par la suite, que ce soit pour demander à l'IA d'intégrer le backend ou pour résoudre vous-même un problème, ce que vous utiliserez le plus souvent est :
|
||||
- `STRIPE_PRICE_PRO_MONTHLY`
|
||||
- `STRIPE_PRICE_PRO_YEARLY`
|
||||
- Les deux `price_id` correspondants
|
||||
:::
|
||||
|
||||
Si vous souhaitez que l'IA vous guide d'abord dans la configuration du tableau de bord, vous pouvez utiliser directement ce prompt :
|
||||
|
||||
```text
|
||||
Je découvre Stripe, ne modifie pas le code pour le moment, guide-moi d'abord pour effectuer la configuration minimale de paiement dans le tableau de bord Stripe.
|
||||
|
||||
Base-toi sur ces documents officiels pour me donner des instructions étape par étape :
|
||||
- https://docs.stripe.com/products-prices/manage-prices
|
||||
- https://docs.stripe.com/checkout/quickstart?lang=node
|
||||
|
||||
Ma situation :
|
||||
- Je veux créer un abonnement payant le plus simple possible
|
||||
- Seulement deux plans : mensuel et annuel
|
||||
- Je ne comprends pas encore les termes Product et Price
|
||||
|
||||
Merci de :
|
||||
1. M'expliquer en termes simples ce que sont Product et Price.
|
||||
2. Puis me guider dans l'ordre « quelle page ouvrir -> où cliquer -> quoi remplir ».
|
||||
3. Enfin me rappeler ce que je dois copier depuis le tableau de bord pour le backend.
|
||||
4. Si je risque de me tromper, me rappeler de rester en mode test.
|
||||
```
|
||||
|
||||
### 6.2 Étape 2 : Préparer les variables d'environnement
|
||||
|
||||
Vous aurez généralement besoin d'au moins ces variables d'environnement :
|
||||
|
||||
- `STRIPE_SECRET_KEY`
|
||||
- `STRIPE_WEBHOOK_SECRET`
|
||||
- `STRIPE_PRICE_PRO_MONTHLY`
|
||||
- `STRIPE_PRICE_PRO_YEARLY`
|
||||
- `APP_URL`
|
||||
- `SUPABASE_URL`
|
||||
- `SUPABASE_SERVICE_ROLE_KEY`
|
||||
|
||||
Vous pouvez ouvrir directement ces pages :
|
||||
|
||||
- Documentation Stripe API Keys : [API keys](https://docs.stripe.com/keys)
|
||||
- Page Stripe Dashboard API Keys : [API Keys](https://dashboard.stripe.com/test/apikeys)
|
||||
- Documentation Stripe Webhooks : [Receive Stripe events in your webhook endpoint](https://docs.stripe.com/webhooks)
|
||||
- Page Stripe Dashboard Webhooks : [Workbench Webhooks](https://dashboard.stripe.com/test/workbench/webhooks)
|
||||
|
||||
> ⚠️ `STRIPE_SECRET_KEY` et `SUPABASE_SERVICE_ROLE_KEY` ne doivent être placés que côté backend.
|
||||
|
||||
::: info L'objectif de cette étape sur les variables d'environnement
|
||||
Cette étape ne vise pas à « remplir le `.env` au maximum », mais à placer les éléments les plus sensibles du système de paiement sous la garde du backend :
|
||||
|
||||
- La clé secrète Stripe
|
||||
- La clé de vérification Webhook
|
||||
- Votre mapping de prix
|
||||
|
||||
En résumé :
|
||||
Le frontend ne fait qu'initier l'achat, les véritables secrets et la logique de tarification doivent rester côté serveur.
|
||||
:::
|
||||
|
||||
Cette étape peut aussi être confiée directement à l'IA :
|
||||
|
||||
```text
|
||||
Regarde d'abord comment mon projet stocke actuellement les variables d'environnement, puis aide-moi à lister celles dont Stripe a besoin.
|
||||
|
||||
Référence-toi à ces documents :
|
||||
- https://docs.stripe.com/keys
|
||||
- https://docs.stripe.com/webhooks
|
||||
|
||||
Ma situation :
|
||||
- Je suis débutant
|
||||
- Je ne distingue pas quelles variables vont au frontend et lesquelles au backend
|
||||
- Je ne suis pas sûr de devoir modifier `.env`, `.env.local` ou un autre fichier
|
||||
|
||||
Merci de :
|
||||
1. Chercher dans le projet où les variables d'environnement sont habituellement stockées.
|
||||
2. Lister les variables minimales nécessaires pour l'intégration Stripe.
|
||||
3. M'expliquer en termes simples le rôle de chaque variable.
|
||||
4. M'indiquer sur quelle page Stripe aller copier chaque variable.
|
||||
5. S'il existe un fichier d'exemple de variables d'environnement dans le projet, ajouter directement les noms de variables.
|
||||
```
|
||||
|
||||
### 6.3 Étape 3 : Le backend crée la Checkout Session
|
||||
|
||||
Vous n'avez pas besoin d'écrire l'interface vous-même, laissez l'IA s'en charger en se référant à la documentation officielle.
|
||||
|
||||
Commencez par lui fournir ces documents :
|
||||
|
||||
- Démarrage rapide Stripe Checkout : [Build a Stripe-hosted checkout page](https://docs.stripe.com/checkout/quickstart?lang=node)
|
||||
- API Checkout Sessions : [Create a Checkout Session](https://docs.stripe.com/api/checkout/sessions/create)
|
||||
- Documentation sur les abonnements : [Subscriptions](https://docs.stripe.com/payments/subscriptions)
|
||||
|
||||
Puis collez directement ce prompt :
|
||||
|
||||
```text
|
||||
Regarde d'abord comment le code backend de mon projet actuel est organisé, puis aide-moi à y intégrer le paiement Stripe.
|
||||
|
||||
Référence-toi à ces documents officiels :
|
||||
- https://docs.stripe.com/checkout/quickstart?lang=node
|
||||
- https://docs.stripe.com/api/checkout/sessions/create
|
||||
- https://docs.stripe.com/payments/subscriptions
|
||||
|
||||
Mon objectif est simple :
|
||||
- Après que l'utilisateur a cliqué sur le bouton d'achat, il est redirigé vers la page de paiement Stripe
|
||||
- Il n'y a que deux plans : mensuel et annuel
|
||||
- Ne me laisse pas décider moi-même où placer le code, analyse d'abord le projet puis place-le au bon endroit
|
||||
|
||||
Merci de :
|
||||
1. Rechercher dans le projet pour identifier le fichier d'entrée backend, les fichiers de route et le format des variables d'environnement.
|
||||
2. En te référant à la documentation officielle, intégrer l'étape « création du lien de paiement Stripe ».
|
||||
3. Ne pas me laisser transmettre le montant moi-même, le prix doit être déterminé par les variables d'environnement du backend.
|
||||
4. M'indiquer quels fichiers tu as modifiés.
|
||||
5. Me dire quelles configurations supplémentaires je dois effectuer dans le tableau de bord Stripe.
|
||||
```
|
||||
|
||||
### 6.4 Étape 4 : Le frontend redirige vers la page de paiement
|
||||
|
||||
L'objectif de cette étape est très simple : faire en sorte que le bouton de la page de tarification appelle votre interface backend, puis redirige vers Stripe Checkout.
|
||||
|
||||
Documentation de référence :
|
||||
|
||||
- Guide d'intégration Stripe Checkout : [Build an integration with Checkout](https://docs.stripe.com/payments/checkout/build-integration)
|
||||
|
||||
Prompt pour l'IA :
|
||||
|
||||
```text
|
||||
Aide-moi à connecter le bouton « Acheter » du projet à Stripe.
|
||||
|
||||
Exigences :
|
||||
- Ne pas modifier les pages existantes, uniquement changer la logique après le clic sur le bouton
|
||||
- Après le clic, appeler l'interface backend pour obtenir le lien de paiement, puis rediriger vers Stripe
|
||||
- En cas d'erreur, afficher un message simple à l'utilisateur (par exemple « Le paiement est temporairement indisponible, veuillez réessayer plus tard »)
|
||||
|
||||
Documentation de référence : https://docs.stripe.com/payments/checkout/build-integration
|
||||
```
|
||||
|
||||
### 6.5 Étape 5 : Le Webhook met à jour l'état dans la base de données
|
||||
|
||||
C'est l'étape la plus critique.
|
||||
|
||||
::: info Pourquoi cette étape est-elle la plus critique
|
||||
Beaucoup de gens pensent que « l'utilisateur a payé et a été redirigé vers la page de succès » signifie que c'est terminé.
|
||||
|
||||
Non.
|
||||
|
||||
Pour votre système, ce qui compte vraiment est :
|
||||
**Stripe a-t-il officiellement envoyé l'événement à votre Webhook, et votre backend a-t-il réussi à mettre à jour l'état dans la base de données ?**
|
||||
:::
|
||||
|
||||
Vous pouvez également demander à l'IA d'implémenter directement cette étape en suivant la documentation officielle des Webhooks Stripe, sans l'écrire manuellement.
|
||||
|
||||
Documentation de référence :
|
||||
|
||||
- Stripe Webhooks : [Receive Stripe events in your webhook endpoint](https://docs.stripe.com/webhooks)
|
||||
- Stripe CLI : [Stripe CLI](https://docs.stripe.com/stripe-cli)
|
||||
- Utilisation de Stripe CLI : [Use the Stripe CLI](https://docs.stripe.com/stripe-cli/use-cli)
|
||||
|
||||
Prompt pour l'IA :
|
||||
|
||||
```text
|
||||
Continue à m'aider à intégrer l'étape « activation automatique après un paiement réussi » avec Stripe.
|
||||
|
||||
Référence-toi à ces documents officiels :
|
||||
- https://docs.stripe.com/webhooks
|
||||
- https://docs.stripe.com/stripe-cli
|
||||
- https://docs.stripe.com/stripe-cli/use-cli
|
||||
|
||||
Mon objectif :
|
||||
- Après que l'utilisateur a payé, il ne s'agit pas simplement d'être redirigé vers la page de succès
|
||||
- Il faut réellement mettre à jour le statut d'abonnement dans ma base de données
|
||||
|
||||
Merci de :
|
||||
1. Rechercher d'abord dans le projet comment le code lié à la base de données et le statut utilisateur sont stockés.
|
||||
2. Ajouter le webhook Stripe.
|
||||
3. Après un paiement réussi, passer l'utilisateur en statut actif, ou mettre à jour le champ de statut d'abonnement déjà utilisé dans le projet.
|
||||
4. S'il existe déjà des tables d'abonnement, de commandes ou d'utilisateurs dans le projet, continuer à utiliser la structure existante.
|
||||
5. M'indiquer quels fichiers tu as modifiés.
|
||||
6. M'expliquer comment tester localement si cette étape fonctionne réellement.
|
||||
```
|
||||
|
||||
## 7. Prompt pour une intégration rapide par l'IA
|
||||
|
||||
Si vous utilisez un outil comme Codex, Claude Code, Trae ou Cursor, vous pouvez directement coller le prompt suivant pour lui demander d'intégrer le paiement dans votre projet.
|
||||
|
||||
```text
|
||||
Aide-moi à intégrer le paiement Stripe dans le projet actuel. Je veux créer la fonctionnalité d'abonnement payant la plus simple possible qui fonctionne.
|
||||
|
||||
Mes exigences :
|
||||
1. Je suis débutant, commence par analyser le projet toi-même, puis décide où modifier le code.
|
||||
2. Ne me laisse pas juger moi-même la structure des répertoires, des routes ou de la base de données.
|
||||
3. Je veux uniquement la version la plus simple : deux plans, mensuel et annuel.
|
||||
4. Après que l'utilisateur a cliqué sur Acheter, il est redirigé vers la page de paiement Stripe.
|
||||
5. Après un paiement réussi, le statut d'abonnement dans ma base de données passe à activé.
|
||||
6. N'ajoute pas trop de fonctionnalités complexes au début, comme des coupons, des montées ou descentes de grade, des factures complexes.
|
||||
|
||||
Résultat attendu :
|
||||
1. Donne-moi d'abord un plan de modifications.
|
||||
2. Modifie ensuite directement le code.
|
||||
3. Explique-moi ensuite comment tester étape par étape en local.
|
||||
4. S'il y a des étapes nécessitant des opérations dans le tableau de bord Stripe, donne-moi directement le lien et les points clés.
|
||||
```
|
||||
|
||||
Si vous souhaitez que l'IA soit plus adaptée à votre projet, vous pouvez également ajouter en début de prompt :
|
||||
|
||||
- Votre framework frontend
|
||||
- La structure des répertoires de votre backend
|
||||
- Les noms de vos tables de base de données
|
||||
- Que votre système utilisateur est Supabase Auth ou un système Auth personnalisé
|
||||
|
||||
## 7.1 Déléguer également les tests d'intégration locaux à l'IA
|
||||
|
||||
Si vous souhaitez que l'IA vous guide même pour les tests d'intégration locaux, vous pouvez utiliser directement ce prompt :
|
||||
|
||||
```text
|
||||
Continue à m'aider à faire fonctionner réellement le paiement Stripe. Je veux suivre étape par étape, sans avoir à deviner.
|
||||
|
||||
Référence-toi à la documentation officielle :
|
||||
- https://docs.stripe.com/webhooks
|
||||
- https://docs.stripe.com/stripe-cli
|
||||
- https://docs.stripe.com/stripe-cli/use-cli
|
||||
|
||||
Mon objectif :
|
||||
1. Dis-moi d'abord quelles pages Stripe ouvrir.
|
||||
2. Explique-moi comment obtenir le STRIPE_WEBHOOK_SECRET.
|
||||
3. Explique-moi comment utiliser stripe login et stripe listen.
|
||||
4. Montre-moi comment vérifier que checkout.session.completed a bien atteint le webhook local.
|
||||
5. Si le projet nécessite de lancer d'abord le frontend et le backend, donne-moi aussi les commandes spécifiques.
|
||||
6. Ne te contente pas de théorie, donne-moi les étapes opérationnelles concrètes.
|
||||
7. Si je me trompe à une étape, dis-moi à quoi ressemblent les erreurs les plus courantes.
|
||||
```
|
||||
|
||||
## 8. Les 4 pièges les plus fréquents
|
||||
|
||||
1. **Considérer la page `success` comme un paiement réussi**
|
||||
Ce qui détermine réellement le statut, c'est le Webhook, pas la redirection frontend.
|
||||
2. **Laisser le frontend transmettre le montant**
|
||||
Cela crée un risque sérieux de falsification du prix.
|
||||
3. **La route Webhook est pré-traitée par `express.json()`**
|
||||
La vérification de signature Stripe nécessite le corps brut de la requête.
|
||||
4. **Absence de traitement idempotent**
|
||||
Les Webhooks peuvent être renvoyés. Si vous ajoutez un abonnement ou des crédits à chaque fois, vous créez un incident.
|
||||
|
||||
## 9. Recommandation de sélection en une phrase
|
||||
|
||||
Si vous voulez simplement faire fonctionner la facturation dès maintenant :
|
||||
|
||||
| Vos utilisateurs principaux | Solution à essayer en premier |
|
||||
| :--- | :--- |
|
||||
| SaaS international / utilisateurs étrangers | Stripe |
|
||||
| Utilisateurs en Chine continentale | Alipay / WeChat Pay |
|
||||
| Hong Kong ou équipes transfrontalières | Stripe + solution agrégée portefeuille local / FPS |
|
||||
|
||||
Les détails spécifiques sont regroupés en annexe.
|
||||
|
||||
::: info L'approche de sélection la plus simple
|
||||
Ne commencez pas par vouloir « intégrer tous les moyens de paiement du monde d'un coup ».
|
||||
|
||||
L'ordre plus pragmatique est généralement :
|
||||
- Choisir d'abord une chaîne de paiement principale selon la région de vos utilisateurs principaux
|
||||
- Faire fonctionner le paiement minimum viable
|
||||
- Puis ajouter un deuxième, puis un troisième moyen de paiement selon les sources réelles d'utilisateurs
|
||||
:::
|
||||
|
||||
## 10. Résumé
|
||||
|
||||
Vous maîtrisez désormais la chaîne de facturation la plus basique mais la plus importante :
|
||||
|
||||
1. Le frontend initie l'achat.
|
||||
2. Le backend crée une Checkout Session.
|
||||
3. L'utilisateur paie sur la page Stripe.
|
||||
4. Stripe notifie le backend via un Webhook.
|
||||
5. Le backend met à jour la base de données.
|
||||
6. Le frontend affiche le nouveau statut d'abonnement ou de commande après actualisation.
|
||||
|
||||
Si vous souhaitez simplement intégrer rapidement le paiement dans votre projet, le contenu précédent suffit. Les annexes ci-dessous sont à consulter lorsque vous rencontrerez réellement des problèmes.
|
||||
|
||||
---
|
||||
|
||||
# Annexes
|
||||
|
||||
## Annexe A : Les objets les plus courants dans Stripe
|
||||
|
||||
Lorsque vous lisez la documentation Stripe pour la première fois, ces noms d'objets peuvent facilement vous désorienter. Vous n'avez en réalité besoin de comprendre que les quelques suivants :
|
||||
|
||||
| Objet | Rôle | À quoi vous pouvez le comparer |
|
||||
| :--- | :--- | :--- |
|
||||
| `Product` | Décrit ce qui est vendu | Un produit ou un plan d'abonnement |
|
||||
| `Price` | Décrit le prix et le cycle de facturation | Mensuel, annuel, achat unique |
|
||||
| `Checkout Session` | Flux de paiement hébergé par Stripe | La page de paiement |
|
||||
| `Subscription` | Relation d'abonnement récurrent | Abonnement à renouvellement automatique |
|
||||
| `Customer` | L'utilisateur qui paie | Le dossier client dans Stripe |
|
||||
| `Webhook` | Notification asynchrone | Stripe vous indique « que s'est-il passé avec ce paiement » |
|
||||
|
||||
## Annexe B : Pourquoi la page `success` ne signifie pas que le paiement a réussi
|
||||
|
||||
Beaucoup de gens pensent que « l'utilisateur a payé et a été redirigé vers la page de succès » équivaut à un paiement réussi. C'est le piège le plus fréquent.
|
||||
|
||||
### Un scénario réel
|
||||
|
||||
Supposons que vous ayez créé un site d'abonnement :
|
||||
1. L'utilisateur clique sur « Acheter un abonnement »
|
||||
2. Redirection vers la page de paiement Stripe
|
||||
3. L'utilisateur saisit sa carte bancaire et clique sur payer
|
||||
4. La page redirige vers votre `success.html`
|
||||
5. Vous avez écrit du code sur la page success : « puisque l'on est sur cette page, activer l'abonnement pour l'utilisateur »
|
||||
|
||||
**Où est le problème ?**
|
||||
|
||||
L'utilisateur peut ne pas avoir payé du tout, ou avoir quitté la page en cours de paiement, et quand même accéder directement à `success.html`.
|
||||
|
||||
### Deux chemins totalement différents
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
pay["L'utilisateur a effectué le paiement sur Stripe"]
|
||||
|
||||
subgraph unreliable["❌ Chemin non fiable : se fier uniquement à la page success"]
|
||||
success["Le navigateur redirige vers la page success"]
|
||||
fake["Le code frontend considère l'abonnement activé"]
|
||||
risk["Risque : page fermée / coupure réseau / URL falsifiée / aucun paiement effectué"]
|
||||
success --> fake --> risk
|
||||
end
|
||||
|
||||
subgraph reliable["✅ Chemin fiable : se fier au Webhook backend"]
|
||||
event["Le serveur Stripe envoie un Webhook"]
|
||||
verify["Le backend vérifie la signature"]
|
||||
active["La base de données est officiellement mise à jour comme payée"]
|
||||
event --> verify --> active
|
||||
end
|
||||
|
||||
pay --> success
|
||||
pay --> event
|
||||
```
|
||||
|
||||
**Différences clés :**
|
||||
|
||||
| | Redirection vers la page success | Notification Webhook |
|
||||
| :--- | :--- | :--- |
|
||||
| Qui initie | Le navigateur de l'utilisateur | Le serveur de Stripe |
|
||||
| Peut être falsifié | Oui, il suffit d'accéder directement à l'URL | Non, il y a une vérification de signature |
|
||||
| Garantit le succès du paiement | Pas nécessairement | Oui, garanti |
|
||||
| Comment votre système le sait | Le code frontend devine | Notification officielle de Stripe |
|
||||
|
||||
### Quel devrait être le flux complet
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor User as Utilisateur
|
||||
participant Frontend as Votre page web
|
||||
participant Stripe as Stripe
|
||||
participant Webhook as Votre interface backend
|
||||
participant DB as Base de données
|
||||
|
||||
User->>Stripe: Effectue le paiement sur la page Stripe
|
||||
Note over Stripe: L'argent est réellement arrivé sur le compte Stripe
|
||||
|
||||
Stripe-->>Frontend: Le navigateur redirige vers la page success
|
||||
Note over Frontend: ⚠️ Ceci est uniquement une redirection<br/>et non une confirmation système
|
||||
|
||||
Stripe->>Webhook: Envoie une notification Webhook<br/>"checkout.session.completed"
|
||||
Note over Webhook: ✅ C'est la notification officielle
|
||||
|
||||
Webhook->>Webhook: Vérifie la signature<br/>(pour confirmer que c'est bien Stripe, pas un hacker)
|
||||
|
||||
Webhook->>DB: Met à jour le statut utilisateur à "payé"
|
||||
DB-->>Webhook: Enregistrement réussi
|
||||
Webhook-->>Stripe: Retourne 200 OK
|
||||
|
||||
Frontend->>DB: L'utilisateur actualise la page, interroge le statut
|
||||
DB-->>Frontend: Retourne "payé"
|
||||
Note over Frontend: C'est seulement à ce moment que les fonctionnalités premium sont affichées
|
||||
```
|
||||
|
||||
### Les points critiques de chaque étape
|
||||
|
||||
**Étape 1 : L'utilisateur paie sur Stripe**
|
||||
|
||||
C'est le seul moment où l'on peut affirmer « l'argent a réellement été payé » :
|
||||
- L'utilisateur saisit les informations de sa carte et clique sur confirmer
|
||||
- La banque débite la carte de l'utilisateur
|
||||
- Stripe confirme avoir reçu le paiement
|
||||
|
||||
**Étape 2 : Le navigateur redirige vers la page success (le plus problématique)**
|
||||
|
||||
Cette étape est totalement non fiable, car :
|
||||
- L'utilisateur peut saisir directement `yoursite.com/success` dans le navigateur et y accéder sans avoir payé
|
||||
- L'utilisateur a quitté la page en cours de paiement, mais avait copié le lien success auparavant, puis l'a ouvert plus tard
|
||||
- Un problème réseau peut empêcher la redirection, alors que l'argent a été débité (l'utilisateur a payé mais ne voit pas la page de succès)
|
||||
- L'utilisateur clique sur le bouton retour et paie deux fois, mais les deux fois il est redirigé vers la même page success
|
||||
|
||||
**Étape 3 : Stripe envoie le Webhook**
|
||||
|
||||
C'est Stripe qui notifie proactivement votre serveur que « ce paiement a été reçu » :
|
||||
- Seul le serveur de Stripe peut initier cette requête
|
||||
- La requête contient une signature que votre backend peut vérifier pour confirmer qu'elle provient bien de Stripe
|
||||
- Même si la page success ne s'est pas ouverte ou si l'utilisateur a été déconnecté, le Webhook est tout de même envoyé
|
||||
|
||||
**Étape 4 : Le backend vérifie la signature**
|
||||
|
||||
Pourquoi vérifier ? Pour empêcher les hackers de falsifier les notifications.
|
||||
|
||||
Supposons qu'il n'y ait pas de vérification : un hacker pourrait envoyer directement une fausse notification à votre serveur : « l'utilisateur A a payé 1000 euros ». Votre système activerait alors l'abonnement pour le hacker.
|
||||
|
||||
Le processus de vérification :
|
||||
- Stripe génère une signature à partir du contenu de la notification en utilisant la clé secrète convenue
|
||||
- Votre backend vérifie avec la même clé si la signature correspond
|
||||
- Correspondance = 100% certain que c'est Stripe, non-correspondance = rejet immédiat
|
||||
|
||||
**Étape 5 : Mise à jour de la base de données**
|
||||
|
||||
Ce n'est qu'après vérification réussie que la base de données est mise à jour :
|
||||
- Passer le statut utilisateur de « en attente de paiement » à « payé »
|
||||
- Enregistrer le numéro de commande, le montant, l'heure du paiement
|
||||
- Activer les droits d'abonnement correspondants
|
||||
|
||||
**Étape 6 : Le frontend interroge le statut**
|
||||
|
||||
La page success ne doit pas considérer que « être sur cette page signifie le succès ». La bonne approche est :
|
||||
- Au chargement de la page, envoyer une requête au backend : « cet utilisateur a-t-il payé ? »
|
||||
- Le backend interroge la base de données et retourne le statut réel
|
||||
- Afficher « activation réussie » ou « en attente de confirmation » selon le résultat
|
||||
|
||||
### Une erreur courante
|
||||
|
||||
```javascript
|
||||
// Erreur : activer directement sur la page success
|
||||
// success.html
|
||||
if (window.location.pathname === '/success') {
|
||||
// Dangereux ! N'importe qui peut accéder /success
|
||||
activateMembership();
|
||||
}
|
||||
```
|
||||
|
||||
```javascript
|
||||
// Correct : interroger le backend à chaque actualisation
|
||||
// success.html
|
||||
async function checkStatus() {
|
||||
const response = await fetch('/api/user/status');
|
||||
const data = await response.json();
|
||||
|
||||
if (data.paymentStatus === 'paid') {
|
||||
showMemberFeatures();
|
||||
} else {
|
||||
showPendingMessage();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Résumé en une phrase
|
||||
|
||||
**La page success est uniquement une « redirection réussie du navigateur », le Webhook est la « confirmation officielle de réception par Stripe ».**
|
||||
|
||||
Votre système doit se fier au Webhook, pas à la redirection frontend.
|
||||
|
||||
## Annexe C : Les événements les plus importants à surveiller pour un système d'abonnement
|
||||
|
||||
| Événement | Signification | Action habituelle |
|
||||
| :--- | :--- | :--- |
|
||||
| `checkout.session.completed` | Première activation réussie | Créer l'enregistrement d'abonnement local |
|
||||
| `invoice.paid` | Renouvellement automatique réussi | Prolonger la date de validité |
|
||||
| `invoice.payment_failed` | Échec du prélèvement automatique | Marquer le statut à risque et alerter l'utilisateur |
|
||||
| `customer.subscription.deleted` | Abonnement annulé | Retirer les droits ou marquer l'expiration |
|
||||
|
||||
### Diagramme d'états de l'abonnement
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> NotStarted: Utilisateur non abonné
|
||||
NotStarted --> Active: checkout.session.completed
|
||||
Active --> Active: invoice.paid
|
||||
Active --> PastDue: invoice.payment_failed
|
||||
PastDue --> Active: L'utilisateur paie avec succès
|
||||
Active --> Canceled: customer.subscription.deleted
|
||||
PastDue --> Canceled: Expiré sans régularisation
|
||||
Canceled --> [*]
|
||||
|
||||
state "Non activé" as NotStarted
|
||||
state "Abonnement actif" as Active
|
||||
state "Prélèvement échoué / En attente" as PastDue
|
||||
state "Annulé / Expiré" as Canceled
|
||||
```
|
||||
|
||||
### Diagramme de séquence : renouvellement / échec / annulation
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant Stripe as Stripe
|
||||
participant Webhook as Votre interface Webhook
|
||||
participant DB as Table abonnements / commandes
|
||||
participant App as Votre application
|
||||
actor User as Utilisateur
|
||||
|
||||
rect rgb(235, 248, 255)
|
||||
Stripe->>Webhook: invoice.paid
|
||||
Webhook->>DB: Prolonger current_period_end
|
||||
DB-->>Webhook: Mise à jour réussie
|
||||
Webhook-->>Stripe: 200 OK
|
||||
App-->>User: L'abonnement reste actif
|
||||
end
|
||||
|
||||
rect rgb(255, 247, 237)
|
||||
Stripe->>Webhook: invoice.payment_failed
|
||||
Webhook->>DB: Marquer past_due
|
||||
DB-->>Webhook: Mise à jour réussie
|
||||
Webhook-->>Stripe: 200 OK
|
||||
App-->>User: Rappel de mettre à jour le moyen de paiement
|
||||
end
|
||||
|
||||
rect rgb(254, 242, 242)
|
||||
Stripe->>Webhook: customer.subscription.deleted
|
||||
Webhook->>DB: Marquer canceled
|
||||
DB-->>Webhook: Mise à jour réussie
|
||||
Webhook-->>Stripe: 200 OK
|
||||
App-->>User: Suspension des droits premium
|
||||
end
|
||||
```
|
||||
|
||||
## Annexe D : Comment choisir parmi les autres solutions de paiement
|
||||
|
||||
### 1. Chine continentale
|
||||
|
||||
Si vos utilisateurs principaux sont en Chine continentale, le premier choix reste **[Alipay](https://open.alipay.com/)** et **[WeChat Pay](https://pay.wechatpay.cn/)**.
|
||||
|
||||
**Modèle de gestion :**
|
||||
|
||||
Les deux fonctionnent en mode « passerelle de paiement ». Vous devez :
|
||||
- Demander une qualification de commerçant (licence commerciale, compte bancaire professionnel)
|
||||
- L'argent payé par les utilisateurs arrive directement sur votre compte commerçant
|
||||
- Vous êtes responsable de la fiscalité, des remboursements et du rapprochement comptable
|
||||
|
||||
**Modèle technique :**
|
||||
|
||||
Les deux adoptent le modèle « commande backend + appel frontend + notification backend », comme Stripe.
|
||||
|
||||
**Processus d'intégration Alipay :**
|
||||
1. Créer une application sur la plateforme ouverte Alipay
|
||||
2. Configurer les clés publique/privée et l'URL de callback
|
||||
3. Le backend appelle l'interface de création de commande pour générer un lien ou un QR code de paiement
|
||||
4. L'utilisateur scanne le code ou est redirigé pour payer
|
||||
5. Alipay notifie votre backend de manière asynchrone pour mettre à jour le statut de la commande
|
||||
|
||||
**Processus d'intégration WeChat Pay :**
|
||||
- Paiement JSAPI : adapté aux comptes officiels et mini-programmes WeChat, l'utilisateur paie directement dans WeChat
|
||||
- Paiement Native : génère un QR code sur PC, l'utilisateur scanne pour payer
|
||||
- Paiement H5 : le navigateur mobile ouvre l'application WeChat pour payer
|
||||
|
||||
Processus : commande backend -> obtention de `prepay_id` ou `code_url` -> appel frontend -> réception de la notification backend confirmant le succès
|
||||
|
||||
**Liens de référence :**
|
||||
- Plateforme ouverte Alipay : https://open.alipay.com/
|
||||
- Documentation commerçant WeChat Pay : https://pay.wechatpay.cn/doc/v3/merchant/
|
||||
|
||||
### 2. Hong Kong
|
||||
|
||||
Le marché de Hong Kong est assez mixte, avec des combinaisons courantes :
|
||||
|
||||
- Cartes bancaires : Visa / Mastercard
|
||||
- FPS (Fast Payment System) : virement instantané local à Hong Kong
|
||||
- AlipayHK / WeChat Pay HK : versions hongkongaises d'Alipay et WeChat
|
||||
|
||||
**Combinaison recommandée :**
|
||||
- Utiliser **[Stripe](https://stripe.com/hk)** pour les cartes internationales et les abonnements
|
||||
- Utiliser **[Airwallex](https://www.airwallex.com/)** ou **[Adyen](https://www.adyen.com/)** pour les portefeuilles locaux et FPS
|
||||
|
||||
### 3. International / SaaS
|
||||
|
||||
#### [Stripe](https://stripe.com/)
|
||||
|
||||
**Modèle de gestion :** Passerelle de paiement
|
||||
|
||||
- Vous devez demander vous-même une qualification de commerçant (Stripe peut s'en charger dans certains pays)
|
||||
- L'argent payé par les utilisateurs arrive sur votre compte Stripe, puis est reversé sur votre compte bancaire
|
||||
- Vous êtes responsable de vos déclarations fiscales
|
||||
|
||||
**Modèle technique :**
|
||||
|
||||
- Meilleure expérience API, documentation claire
|
||||
- Prend en charge Checkout (page hébergée), Elements (formulaire personnalisé), Payment Links (sans code)
|
||||
- Notification de l'état du paiement par Webhook
|
||||
- Prend en charge les abonnements, les factures, les devises multiples
|
||||
|
||||
**Pour qui :** SaaS international, développeurs indépendants, équipes nécessitant une personnalisation flexible
|
||||
|
||||
**Lien de référence :** https://docs.stripe.com/
|
||||
|
||||
#### [PayPal](https://www.paypal.com/)
|
||||
|
||||
**Modèle de gestion :** Passerelle de paiement
|
||||
|
||||
- L'argent payé par les utilisateurs arrive sur votre compte PayPal, puis vous le retirez sur votre banque
|
||||
- Vous êtes responsable de la fiscalité
|
||||
|
||||
**Modèle technique :**
|
||||
|
||||
- Paiement unique : bouton sur le frontend, création/confirmation de commande par le backend
|
||||
- Abonnement : créer d'abord un Product et un Plan, puis utiliser le SDK pour lancer
|
||||
- Nécessite également un backend et des Webhooks, ne pas se fier uniquement au callback frontend
|
||||
|
||||
**Pour qui :** Activités internationales nécessitant un canal supplémentaire, utilisateurs habitués à payer avec PayPal
|
||||
|
||||
**Lien de référence :** https://developer.paypal.com/docs/
|
||||
|
||||
#### [Paddle](https://www.paddle.com/)
|
||||
|
||||
**Modèle de gestion :** Merchant of Record (MoR)
|
||||
|
||||
- Paddle est le « commerçant inscrit », juridiquement c'est Paddle qui encaisse auprès de l'utilisateur
|
||||
- Paddle gère pour vous la fiscalité mondiale, la TVA, les remboursements, la conformité
|
||||
- L'argent payé par les utilisateurs arrive à Paddle, qui déduit taxes et frais puis vous reverse le solde
|
||||
- Vous n'avez pas besoin de créer une société dans chaque pays ni de gérer la fiscalité
|
||||
|
||||
**Modèle technique :**
|
||||
|
||||
- Paddle.js : page de paiement hébergée intégrée au frontend
|
||||
- API backend : crée une transaction, la confie au checkout
|
||||
- Webhook pour synchroniser le statut de l'abonnement
|
||||
|
||||
**Pour qui :** Équipes SaaS ne souhaitant pas gérer la fiscalité mondiale, en particulier les SaaS B2B
|
||||
|
||||
**Lien de référence :** https://developer.paddle.com/
|
||||
|
||||
#### [Lemon Squeezy](https://www.lemonsqueezy.com/)
|
||||
|
||||
**Modèle de gestion :** Merchant of Record (MoR)
|
||||
|
||||
- Similaire à Paddle, Lemon Squeezy est le « commerçant inscrit »
|
||||
- Gère la fiscalité mondiale, la TVA, la conformité
|
||||
- Racheté par Stripe en 2024, mais fonctionne indépendamment
|
||||
|
||||
**Modèle technique :**
|
||||
|
||||
- Hosted Checkout : le plus simple, génère directement un lien de paiement
|
||||
- Checkout Overlay : surcouche intégrée à votre page
|
||||
- API backend : crée un checkout, pour un contrôle flexible
|
||||
|
||||
**Pour qui :** Développeurs indépendants, produits numériques, licences logicielles
|
||||
|
||||
**Lien de référence :** https://docs.lemonsqueezy.com/
|
||||
|
||||
### 4. Solutions d'entreprise
|
||||
|
||||
#### [Airwallex](https://www.airwallex.com/)
|
||||
|
||||
**Modèle de gestion :** Passerelle de paiement + comptes globaux
|
||||
|
||||
- Fournit des comptes de réception mondiaux (similaires à des comptes bancaires virtuels)
|
||||
- Prend en charge la réception dans plusieurs devises, les conversions et les paiements
|
||||
- Vous êtes responsable de la fiscalité
|
||||
|
||||
**Modèle technique :**
|
||||
|
||||
- Payment Links : quasi sans code, génère un lien de paiement
|
||||
- Hosted Payment Page : page hébergée
|
||||
- Drop-in / Embedded / Native API : intégration profonde, haut niveau de personnalisation
|
||||
- Prend en charge Alipay HK, FPS, WeChat Pay et autres moyens de paiement locaux
|
||||
|
||||
**Pour qui :** Équipes à Hong Kong, activités transfrontalières, entreprises nécessitant des comptes multidevises
|
||||
|
||||
**Lien de référence :** https://www.airwallex.com/docs/
|
||||
|
||||
#### [Adyen](https://www.adyen.com/)
|
||||
|
||||
**Modèle de gestion :** Passerelle de paiement
|
||||
|
||||
- Plateforme de paiement de niveau entreprise, traitant des billions d'euros de transactions par an
|
||||
- Prend en charge tous les canaux : en ligne, en point de vente, mobile
|
||||
- Vous êtes responsable de la fiscalité
|
||||
|
||||
**Modèle technique :**
|
||||
|
||||
- Pay by Link : le plus simple, génère un lien de paiement
|
||||
- Drop-in / Components : intégration en ligne standard
|
||||
- Possibilité d'activer Alipay, Alipay HK, PayMe et autres moyens locaux depuis le tableau de bord
|
||||
|
||||
**Pour qui :** Grandes entreprises, entreprises nécessitant un paiement omnicanal
|
||||
|
||||
**Lien de référence :** https://docs.adyen.com/
|
||||
|
||||
### 5. Comparaison des solutions
|
||||
|
||||
| Solution | Modèle de gestion | Gestion fiscale | Pour qui |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| Stripe | Passerelle de paiement | À votre charge | SaaS international, développeurs |
|
||||
| PayPal | Passerelle de paiement | À votre charge | Canal supplémentaire international |
|
||||
| Paddle | MoR | Géré par Paddle | SaaS B2B, sans gestion fiscale |
|
||||
| Lemon Squeezy | MoR | Géré par LS | Développeurs indépendants, produits numériques |
|
||||
| Adyen | Passerelle de paiement | À votre charge | Grandes entreprises |
|
||||
| Airwallex | Passerelle + comptes | À votre charge | Activités transfrontalières, équipes HK |
|
||||
| Alipay/WeChat | Passerelle de paiement | À votre charge | Utilisateurs en Chine |
|
||||
|
||||
### 6. Choix par région
|
||||
|
||||
| Votre marché | Solution recommandée |
|
||||
| :--- | :--- |
|
||||
| Chine continentale | Alipay / WeChat Pay |
|
||||
| Hong Kong | Stripe + Airwallex / Adyen |
|
||||
| SaaS international | Stripe (vous gérez la fiscalité) ou Paddle (MoR, géré pour vous) |
|
||||
| Produits numériques internationaux | Stripe / Lemon Squeezy / Paddle |
|
||||
| Multi-régions entreprise | Combinaison Adyen / Airwallex / Stripe |
|
||||
@@ -0,0 +1,490 @@
|
||||
# Comment déployer une application web
|
||||
|
||||
Dans ce tutoriel, nous allons présenter comment déployer votre application web sur Internet pour que d'autres personnes puissent y accéder. Nous présenterons trois plateformes de déploiement courantes : **Tencent CloudBase**, **Vercel** et **Zeabur**, pour vous aider à réaliser rapidement le processus complet, du « code écrit » au « site accessible sur Internet par tous ».
|
||||
|
||||
# Qu'est-ce que le « déploiement » ?
|
||||
|
||||
Avant de commencer, clarifions ce que signifie « déploiement (Deployment) ». Pour qu'un site web soit accessible par des utilisateurs externes, il doit disposer d'une adresse réseau publiquement accessible (cette adresse peut être une adresse IP, comme 123.45.67.89, ou un nom de domaine, comme [google.com](https://google.com/)). Mais une adresse seule ne suffit pas — votre code de page web (fichiers HTML, CSS, JavaScript, ou projets utilisant des frameworks comme React, Vue, etc.), ainsi que les ressources associées (images, vidéos), doivent être « placés » sur un serveur en ligne 24h/24, qui répondra aux requêtes réseau. Ainsi, le navigateur de n'importe qui pourra accéder à ces ressources et les télécharger.
|
||||
|
||||
|
||||
|
||||
Source de l'image : https://www.hostinger.com/tutorials/what-is-cloud-hosting
|
||||
|
||||
L'ensemble du processus — téléchargement des ressources, configuration de l'environnement et mise en route du service — est appelé **déploiement (Deployment)**.
|
||||
|
||||
En termes simples : les pages web que vous avez écrites sur votre ordinateur ne sont accessibles que via une adresse locale dans votre propre navigateur, car ce code n'existe que sur votre disque dur. Le « déploiement » consiste à transférer votre code et vos ressources vers un serveur professionnel connecté au réseau public, et à le configurer pour qu'il sache « comment répondre lorsqu'on m'accède » — par exemple : quand quelqu'un saisit votre nom de domaine dans son navigateur, le serveur trouve immédiatement les fichiers correspondants et renvoie le contenu à l'appareil de l'utilisateur, qui peut alors voir votre page.
|
||||
|
||||
Un déploiement manuel nécessite souvent plusieurs étapes, chacune pouvant comporter des pièges. Les étapes clés courantes incluent :
|
||||
|
||||
1. **Préparation du serveur** : vous devez d'abord acheter un serveur cloud (comme Alibaba Cloud, Tencent Cloud, ou AWS EC2), choisir la région du serveur (Shanghai, Singapour, etc.), sa configuration (CPU, mémoire, taille du disque, etc.), et apprendre à vous y connecter à distance (par exemple via SSH).
|
||||
|
||||
2. **Configuration de l'environnement** : une application web a besoin d'un « environnement » spécifique pour fonctionner — par exemple, exécuter un projet Node.js nécessite d'abord installer Node.js ; exécuter un projet Python nécessite d'installer Python et les bibliothèques tierces correspondantes. Si la version de l'environnement ne correspond pas, le programme peut générer des erreurs ou ne pas démarrer.
|
||||
3. **Téléchargement des ressources** : vous devez uploader votre code et vos ressources locales vers le serveur, généralement via FTP ou Git. Si le projet est volumineux (contenant par exemple des fichiers vidéo), une interruption en cours de route peut nécessiter un re-upload complet.
|
||||
|
||||
|
||||
|
||||
4. **Démarrage du service et tests** : une fois l'upload terminé, vous devez exécuter des commandes sur le serveur pour lancer l'application, et vérifier si « l'adresse réseau attribuée est accessible ». Si ce n'est pas le cas, cela peut être dû au pare-feu du serveur qui n'a pas ouvert le port correspondant (par exemple, votre application écoute le port 3000, mais ce port est bloqué par le pare-feu), ou à un bug dans le programme. Il faut alors consulter les journaux du serveur pour diagnostiquer le problème.
|
||||
> On peut comprendre le port comme le « numéro de chambre » distinguant les différentes applications sur un même appareil, tandis que l'IP est le « numéro de rue » de cet appareil. L'IP et le port combinés (IP:port) permettent de localiser précisément un service réseau.
|
||||
5. **Maintenance et mises à jour** : à chaque modification de code, vous devez re-uploader et redémarrer le service. En cas de panne du serveur (coupure de courant, panne réseau, etc.), vous devez redémarrer manuellement l'application, et parfois configurer un « outil de garde de processus » pour que le programme redémarre automatiquement après une sortie anormale.
|
||||
|
||||
Des plateformes de déploiement « low-code » comme CloudBase, Vercel et Zeabur sont précisément nées pour résoudre ces problèmes complexes. Elles automatisent pour vous les étapes « achat de serveur, configuration d'environnement, upload de code, démarrage du service, surveillance de l'exécution ». Il vous suffit de connecter votre dépôt de code (comme GitHub ou GitLab) à la plateforme, ou d'uploader directement votre code, et elle tirera automatiquement le code, identifiera le type d'application, configurera l'environnement d'exécution correspondant, et vous donnera finalement une adresse publique accessible par tous. Elle peut même lier votre propre nom de domaine en un clic.
|
||||
|
||||
|
||||
|
||||
Ensuite, nous présenterons les caractéristiques et méthodes d'utilisation de ces plateformes pour vous aider à choisir la solution de déploiement la plus adaptée.
|
||||
|
||||
---
|
||||
|
||||
# Comparaison des plateformes de déploiement
|
||||
|
||||
| Plateforme | Caractéristiques | Scénarios d'utilisation | Quota gratuit |
|
||||
|------|------|----------|----------|
|
||||
| **Tencent CloudBase** | Accès rapide en Chine, intégration profonde avec l'écosystème WeChat | Projets principalement destinés aux utilisateurs chinois, nécessitant le support des mini-programmes WeChat | Quota gratuit disponible |
|
||||
| **Vercel** | Bon support des frameworks frontend, intégration étroite avec GitHub | Projets frontend modernes comme React/Vue/Next.js | Quota gratuit disponible |
|
||||
| **Netlify** | Fonctionnalités complètes, support du traitement de formulaires et de l'authentification, bonne intégration Git | Sites statiques nécessitant des fonctionnalités avancées comme le traitement de formulaires, l'authentification | Quota gratuit disponible |
|
||||
| **Zeabur** | Support de multiples langages et templates de services, configuration flexible | Projets complexes nécessitant le déploiement de multiples services (comme Dify, n8n) | Environ 5 USD de quota gratuit par mois |
|
||||
|
||||
---
|
||||
|
||||
# 1. Tencent CloudBase
|
||||
|
||||
Tencent CloudBase (Cloud Development) est un service cloud backend tout-en-un proposé par Tencent Cloud, particulièrement adapté aux développeurs en Chine. Ses avantages sont :
|
||||
|
||||
- **Accès rapide en Chine** : serveurs situés en Chine, faible latence d'accès
|
||||
- **Intégration avec l'écosystème WeChat** : connexion facile avec les mini-programmes et comptes officiels WeChat
|
||||
- **Solution tout-en-un** : fournit un ensemble complet de services incluant l'hébergement de sites statiques, fonctions cloud, base de données, stockage, etc.
|
||||
- **Quota gratuit généreux** : les développeurs individuels disposent de ressources gratuites suffisantes
|
||||
|
||||
## Déployer une application web avec CloudBase
|
||||
|
||||
### Étape 1 : Inscription et connexion
|
||||
|
||||
Accédez à la [console Tencent CloudBase](https://console.cloud.tencent.com/tcb) et connectez-vous avec WeChat ou QQ.
|
||||
|
||||
### Étape 2 : Créer un environnement
|
||||
|
||||
Cliquez sur « Nouvel environnement » et choisissez un nom d'environnement (comme `my-web-app`).
|
||||
|
||||
> **Note** : La version d'essai gratuite de CloudBase nécessite un code d'échange pour être activée. Vous devez suivre le compte officiel Tencent CloudBase, saisir «领取兑换码» dans le compte officiel pour obtenir le code d'échange de la version d'essai gratuite, puis remplir ce code lors de la création de l'environnement pour activer l'environnement gratuit (la période d'essai gratuite est de 6 mois).
|
||||
|
||||
### Étape 3 : Activer l'hébergement de sites statiques
|
||||
|
||||
Dans la page de gestion de l'environnement, trouvez la fonctionnalité « Hébergement de sites statiques » et activez-la. Une fois activée, vous obtiendrez un domaine d'accès par défaut.
|
||||
|
||||
L'hébergement de sites statiques de CloudBase propose plusieurs méthodes de déploiement, similaires à Zeabur :
|
||||
|
||||
- **Upload de projet local** : uploader directement les fichiers statiques construits (HTML, CSS, JS, etc.) depuis le local
|
||||
- **Déploiement par template** : créer rapidement un projet en utilisant des templates prédéfinis, comme les templates d'application web React ou Vue
|
||||
- **Déploiement depuis un dépôt Git** : supporte le pull automatique de code depuis des dépôts comme GitHub et le déploiement
|
||||
|
||||
### Étape 4 : Déployer le code
|
||||
|
||||
Dans la page d'hébergement de sites statiques, CloudBase propose trois méthodes de déploiement :
|
||||
|
||||
**Méthode 1 : Déploiement de projet local (upload de projet local)**
|
||||
- Sélectionnez « Déploiement de projet local » dans la console
|
||||
- Uploadez directement les fichiers statiques construits (HTML, CSS, JS, etc.)
|
||||
- Sélectionnez le dossier de votre projet construit localement (comme le répertoire `dist` ou `build`)
|
||||
- Attendez la fin de l'upload pour accéder au site
|
||||
|
||||
**Méthode 2 : Déploiement par template**
|
||||
- Créez rapidement un projet en utilisant des templates prédéfinis
|
||||
- Supporte les templates d'application web React, Vue, etc.
|
||||
- Construction et déploiement automatiques basés sur le template
|
||||
|
||||
**Méthode 3 : Déploiement depuis un dépôt Git**
|
||||
- **Déploiement de dépôt personnel Git** : liez votre dépôt de code personnel GitHub, etc.
|
||||
- **Déploiement de dépôt public** : supporte le pull de code depuis des dépôts Git publics
|
||||
- Configurez les commandes de build automatique (comme `npm run build`)
|
||||
- Chaque push de code déclenche un redéploiement automatique
|
||||
|
||||
> **Astuce** : vous pouvez aussi utiliser l'outil CLI pour le déploiement :
|
||||
> ```bash
|
||||
> # Installer le CLI CloudBase
|
||||
> npm install -g @cloudbase/cli
|
||||
> # Connexion
|
||||
> tcb login
|
||||
> # Déploiement
|
||||
> tcb hosting deploy ./dist -e your-env-id
|
||||
> ```
|
||||
|
||||
### Étape 5 : Configurer un domaine personnalisé (optionnel)
|
||||
|
||||
Dans les paramètres d'hébergement de sites statiques, vous pouvez lier votre propre domaine et demander un certificat HTTPS gratuit.
|
||||
|
||||
---
|
||||
|
||||
# 2. Vercel
|
||||
|
||||
Vercel est l'une des plateformes de déploiement frontend les plus populaires au monde, particulièrement adaptée au déploiement de projets utilisant des frameworks frontend modernes comme React, Vue, Next.js. Ses caractéristiques incluent :
|
||||
|
||||
- **Intégration profonde avec GitHub** : un push de code déclenche un déploiement automatique
|
||||
- **Prévisualisation automatique** : chaque Pull Request génère un lien de prévisualisation indépendant
|
||||
- **CDN mondial** : le site est automatiquement distribué sur des nœuds worldwide, accès rapide
|
||||
- **Fonctions Serverless** : supporte l'écriture d'API backend dans le projet
|
||||
|
||||
> **Note** : l'accès à Vercel peut être instable dans certains environnements réseau. Les utilisateurs en Chine sont invités à privilégier CloudBase.
|
||||
|
||||
## Déployer une application web avec Vercel
|
||||
|
||||
### Étape 1 : Créer un compte
|
||||
|
||||
Accédez au [site officiel de Vercel](https://vercel.com) et connectez-vous avec votre compte GitHub.
|
||||
|
||||
### Étape 2 : Importer le projet
|
||||
|
||||
1. Cliquez sur « Add New Project »
|
||||
2. Sélectionnez le dépôt GitHub que vous souhaitez déployer
|
||||
3. Si vous ne voyez pas le dépôt souhaité, cliquez sur « Adjust GitHub App Permissions » pour autoriser l'accès
|
||||
|
||||
### Étape 3 : Configurer les paramètres de build
|
||||
|
||||
Vercel identifiera automatiquement le type de projet et configurera les commandes de build :
|
||||
|
||||
| Framework | Commande de build | Répertoire de sortie |
|
||||
|------|----------|----------|
|
||||
| React | `npm run build` | `build` |
|
||||
| Vue | `npm run build` | `dist` |
|
||||
| Next.js | `next build` | - |
|
||||
| HTML pur | - | Répertoire racine du projet |
|
||||
|
||||
Si l'identification automatique n'est pas correcte, vous pouvez modifier manuellement :
|
||||
- **Build Command** : commande de build, comme `npm run build`
|
||||
- **Output Directory** : répertoire de sortie du build, comme `dist` ou `build`
|
||||
- **Install Command** : commande d'installation des dépendances, généralement `npm install`
|
||||
|
||||
### Étape 4 : Déployer
|
||||
|
||||
Cliquez sur le bouton « Deploy » et attendez la fin du build. Une fois le build réussi, vous obtiendrez un domaine `xxx.vercel.app`.
|
||||
|
||||
### Étape 5 : Domaine personnalisé (optionnel)
|
||||
|
||||
Dans la page « Domains » des paramètres du projet, vous pouvez ajouter votre propre domaine. Vercel configurera automatiquement le HTTPS.
|
||||
|
||||
---
|
||||
|
||||
# 3. Netlify
|
||||
|
||||
Netlify est une autre plateforme de déploiement frontend très populaire, similaire à Vercel, particulièrement adaptée au déploiement de sites statiques et d'applications à page unique (SPA). Ses caractéristiques incluent :
|
||||
|
||||
- **Fonctionnalités complètes** : outre l'hébergement de sites statiques, supporte le traitement de formulaires, l'authentification, les fonctions edge, etc.
|
||||
- **Intégration profonde avec Git** : supporte GitHub, GitLab, Bitbucket ; un push de code déclenche le déploiement automatique
|
||||
- **Prévisualisation par branche** : chaque branche génère automatiquement un lien de prévisualisation indépendant
|
||||
- **CDN mondial** : le site est automatiquement distribué sur des nœuds worldwide, accès rapide
|
||||
- **Traitement de formulaires** : traite les soumissions de formulaires sans code backend
|
||||
- **Authentification** : fonctionnalité d'authentification utilisateur intégrée, pour implémenter rapidement connexion/inscription
|
||||
|
||||
> **Note** : la vitesse d'accès à Netlify depuis la Chine peut être inférieure à celle de CloudBase. Recommandé principalement pour les projets ciblant des utilisateurs internationaux.
|
||||
|
||||
## Déployer une application web avec Netlify
|
||||
|
||||
### Étape 1 : Créer un compte
|
||||
|
||||
Accédez au [site officiel de Netlify](https://www.netlify.com) et cliquez sur « Sign up » pour vous inscrire. Vous pouvez utiliser GitHub, GitLab, Bitbucket ou un email.
|
||||
|
||||
### Étape 2 : Importer le projet
|
||||
|
||||
1. Après connexion, cliquez sur « Add new site » -> « Import an existing project »
|
||||
2. Sélectionnez votre plateforme d'hébergement de code (comme GitHub)
|
||||
3. Autorisez Netlify à accéder à vos dépôts
|
||||
4. Sélectionnez dans la liste le dépôt que vous souhaitez déployer
|
||||
|
||||
### Étape 3 : Configurer les paramètres de build
|
||||
|
||||
Netlify identifiera automatiquement les frameworks frontend courants et configurera les paramètres de build :
|
||||
|
||||
| Framework | Commande de build | Répertoire de publication |
|
||||
|------|----------|----------|
|
||||
| React | `npm run build` | `build` |
|
||||
| Vue | `npm run build` | `dist` |
|
||||
| Angular | `ng build` | `dist/<nom-du-projet>` |
|
||||
| Next.js | `next build` | `out` |
|
||||
| HTML pur | - | `.` (répertoire racine du projet) |
|
||||
|
||||
Si l'identification automatique n'est pas correcte, vous pouvez configurer manuellement :
|
||||
- **Build command** : commande de build, comme `npm run build`
|
||||
- **Publish directory** : répertoire de sortie du build, comme `dist` ou `build`
|
||||
|
||||
### Étape 4 : Déployer
|
||||
|
||||
Cliquez sur le bouton « Deploy site » et attendez la fin du build. Une fois le build réussi, vous obtiendrez un domaine `xxx.netlify.app`, accessible par tous.
|
||||
|
||||
### Étape 5 : Configurer un domaine personnalisé (optionnel)
|
||||
|
||||
1. Accédez aux paramètres du site, cliquez sur « Domain management »
|
||||
2. Cliquez sur « Add custom domain »
|
||||
3. Saisissez votre domaine et configurez les enregistrements DNS selon les instructions
|
||||
4. Netlify demandera et configurera automatiquement un certificat HTTPS
|
||||
|
||||
### Fonctionnalités spéciales
|
||||
|
||||
#### 1. Traitement de formulaires
|
||||
|
||||
Netlify offre une fonctionnalité très pratique : le traitement des soumissions de formulaires sans code backend.
|
||||
|
||||
Il suffit d'ajouter l'attribut `netlify` au formulaire HTML :
|
||||
|
||||
```html
|
||||
<form name="contact" netlify>
|
||||
<p>
|
||||
<label>Nom : <input type="text" name="name" /></label>
|
||||
</p>
|
||||
<p>
|
||||
<label>Email : <input type="email" name="email" /></label>
|
||||
</p>
|
||||
<p>
|
||||
<label>Message : <textarea name="message"></textarea></label>
|
||||
</p>
|
||||
<p>
|
||||
<button type="submit">Envoyer</button>
|
||||
</p>
|
||||
</form>
|
||||
```
|
||||
|
||||
Après déploiement, les données soumises via le formulaire seront automatiquement envoyées au tableau de bord Netlify. Vous pouvez consulter toutes les soumissions dans la page « Forms », configurer des notifications par email ou transférer les données vers d'autres services.
|
||||
|
||||
#### 2. Netlify Functions (fonctions edge)
|
||||
|
||||
Netlify supporte le déploiement de fonctions serverless, vous permettant d'implémenter des API simples sans configurer un serveur backend complet. Vous pouvez écrire des fonctions en JavaScript ou TypeScript ; une fois déployées, elles obtiendront automatiquement une URL accessible.
|
||||
|
||||
Par exemple, créez un fichier `hello.js` :
|
||||
|
||||
```javascript
|
||||
exports.handler = async (event, context) => {
|
||||
return {
|
||||
statusCode: 200,
|
||||
body: JSON.stringify({ message: "Hello from Netlify!" })
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
Après déploiement, vous pouvez accéder à cette fonction via `https://votre-domaine/.netlify/functions/hello`.
|
||||
|
||||
#### 3. Support du développement local
|
||||
|
||||
Netlify fournit un outil CLI pour faciliter le développement et les tests en local :
|
||||
|
||||
```bash
|
||||
# Installer le CLI Netlify
|
||||
npm install -g netlify-cli
|
||||
|
||||
# Connexion au compte
|
||||
netlify login
|
||||
|
||||
# Démarrer le serveur de développement local
|
||||
netlify dev
|
||||
|
||||
# Tester les fonctions en local
|
||||
netlify functions:serve
|
||||
```
|
||||
|
||||
L'outil CLI permet de simuler l'environnement Netlify en local, y compris la soumission de formulaires, l'appel de fonctions, etc., facilitant les tests avant le déploiement.
|
||||
|
||||
---
|
||||
|
||||
# 4. Zeabur
|
||||
|
||||
Zeabur est une plateforme de déploiement émergente, particulièrement adaptée aux projets complexes nécessitant le déploiement de multiples services. Ses avantages sont :
|
||||
|
||||
- **Templates de services riches** : templates intégrés pour Dify, n8n, bases de données et bien d'autres services
|
||||
- **Support de multiples méthodes de déploiement** : GitHub, templates, images Docker, projets locaux, etc.
|
||||
- **Combinaison flexible de services** : possibilité de déployer plusieurs services interconnectés dans un seul projet
|
||||
- **Facturation à l'usage** : payez uniquement ce que vous consommez, adapté aux projets expérimentaux
|
||||
|
||||
## Déployer Dify avec Zeabur
|
||||
|
||||
Dans les cours précédents, nous avons brièvement découvert Dify. Maintenant, nous pouvons lancer très facilement notre propre service Dify via [Zeabur](https://zeabur.com/projects). Commencez par ouvrir la [page de la console](https://zeabur.com/projects) et examinons les différentes zones.
|
||||
|
||||
|
||||
|
||||
Sur cette page, vous verrez d'abord plusieurs blocs : ce sont les services déjà lancés. Dans le menu supérieur, vous verrez les options Agent, Servers, Docs, Templates, qui représentent respectivement :
|
||||
|
||||
1. **Agent** : ouvre l'assistant intelligent (Agent) intégré à Zeabur, à qui vous pouvez poser des questions sur les opérations ou consulter l'état actuel du serveur.
|
||||
2. **Servers** : ici vous pouvez ajouter vos propres serveurs cloud achetés, ou acheter directement des serveurs via Zeabur.
|
||||
3. **Docs** : consulter la documentation complète de Zeabur.
|
||||
4. **Templates** : liste de tous les templates d'images intégrés.
|
||||
|
||||
> L'« image (Image) » mentionnée ici peut être comprise comme une « archive contenant le code et l'environnement d'exécution ». Quand un service a été exécuté avec succès sur un serveur, nous pouvons choisir d'empaqueter « cet environnement d'exécution + le code » en une image. Ensuite, sur tout nouveau serveur, il suffit de décompresser et d'exécuter cette archive pour que le service fonctionne directement, sans reconfigurer l'environnement et le code.
|
||||
|
||||
En haut à droite de la page, vous verrez également votre solde. Par défaut, vous disposez d'environ 5 USD de quota gratuit par mois. Vous pouvez ignorer les détails de facturation pour le moment ; retenez simplement que tant que le serveur est en cours d'exécution, le quota est consommé.
|
||||
|
||||
|
||||
|
||||
Cliquez sur le solde pour voir le détail des consommations quotidiennes.
|
||||
|
||||
|
||||
|
||||
Maintenant, créons notre propre service Dify. Tout d'abord, sur la [page d'accueil de la console](https://zeabur.com/projects), cliquez sur « New Project ».
|
||||
|
||||
|
||||
|
||||
Voici l'explication des différentes méthodes de création :
|
||||
|
||||
1. **GitHub**
|
||||
Permet de se connecter à votre compte GitHub. Une fois lié, vous pouvez sélectionner directement un projet depuis vos dépôts GitHub pour le déployer (GitHub est actuellement la plus grande plateforme d'hébergement de code au monde).
|
||||
2. **Template (modèle)**
|
||||
Permet de déployer un service basé sur un template. Zeabur intègre de nombreux templates de projets prédéfinis (comme Dify, n8n, etc.), vous permettant de créer et déployer rapidement une application à partir de ces templates.
|
||||
|
||||
3. **Databases (bases de données)**
|
||||
Pour déployer des services de base de données, comme MySQL, MongoDB et d'autres bases de données courantes.
|
||||
|
||||
4. **Functions (fonctions)**
|
||||
Permet de déployer des services de fonctions. Vous pouvez écrire du code JavaScript ou Python qui sera appelé sous forme de fonctions.
|
||||
|
||||
|
||||
|
||||
|
||||
5. **Local Project (projet local)**
|
||||
Uploadez un dossier local, Zeabur identifiera automatiquement les scripts de démarrage. Idéal pour déployer rapidement sur Zeabur un projet déjà développé localement.
|
||||
|
||||
6. **Docker Image**
|
||||
Déployez une image Docker déjà empaquetée. Si votre projet a été transformé en image Docker (par exemple stockée sur Docker Hub ou un autre registre d'images), vous pouvez la déployer directement ici.
|
||||
|
||||
7. **Cursor**
|
||||
Si vous avez installé Cursor (par exemple Cursor IDE), vous pouvez déployer directement un projet depuis Cursor vers Zeabur via cette entrée.
|
||||
|
||||
Si vous souhaitez déployer votre propre service Dify, il est recommandé de choisir le mode **Template**, puis de saisir « dify » dans la barre de recherche. Vous verrez de nombreuses versions maintenues par différents auteurs ; vous pouvez en choisir une (par exemple la version v1.6.0).
|
||||
|
||||
|
||||
|
||||
Ensuite, saisissez n'importe quel nom. Zeabur générera un domaine personnalisé temporaire basé sur ce nom. Ensuite, tout le monde pourra accéder à votre service via cette URL.
|
||||
|
||||
|
||||
|
||||
Une fois la création terminée, vous verrez plusieurs programmes (services) démarrer successivement. Soyez patient et attendez que tous les services atteignent l'état « démarré ». (Le service Dify est composé de plusieurs programmes, chacun responsable de fonctionnalités différentes, qui collaborent entre eux.)
|
||||
|
||||
En général, il vous suffit de cliquer sur l'application Dify à gauche pour voir l'adresse d'accès par défaut. Mais dans cet exemple, comme il y a une couche nginx supplémentaire devant, vous devez cliquer sur le service nginx pour obtenir l'adresse d'accès finale. On peut comprendre nginx comme le programme principal responsable de « recevoir et distribuer les requêtes » vers l'extérieur : il répartit les adresses d'accès externes vers les différents services internes. Cliquez sur Nginx à gauche, et dans la page de détails vous verrez l'adresse actuelle du service. Ouvrez cette adresse dans votre navigateur et attendez que le service soit complètement démarré.
|
||||
|
||||
|
||||
|
||||
Après quelques instants, vous verrez l'interface de connexion de Dify. Saisissez votre adresse email et votre mot de passe d'inscription, et vous pouvez commencer à utiliser votre propre service Dify.
|
||||
|
||||
|
||||
|
||||
Si vous êtes curieux, vous pouvez aussi en profiter pour lancer un service n8n. n8n est également une plateforme de workflows AI très populaire à l'international.
|
||||
|
||||
|
||||
|
||||
## Déployer un jeu de serpent avec Zeabur et Trae
|
||||
|
||||
Dans cette prochaine partie du tutoriel, nous allons découvrir des utilisations plus avancées de Zeabur. Nous commencerons par générer un petit jeu de serpent avec Trae, puis le déploierons sur le serveur de Zeabur, en configurant un lien publiquement accessible pour que tout le monde puisse ouvrir votre jeu.
|
||||
|
||||
La première étape consiste à créer un projet de jeu de serpent localement avec Trae.
|
||||
|
||||
### Implémentation avec le framework HTML
|
||||
|
||||
|
||||
|
||||
Pour Trae, générer un jeu web de serpent basé sur HTML est très simple. Une fois le jeu généré, il vous suffit de suivre la méthode de déploiement local de Zeabur présentée précédemment pour uploader le dossier contenant tous les fichiers.
|
||||
|
||||
|
||||
|
||||
Une fois terminé, vous accéderez à l'interface de détails du service :
|
||||
|
||||
|
||||
|
||||
Cliquez sur l'option « Network » à gauche, et trouvez la zone « Public Address » dans la page. Cliquez sur « Generate Domain » pour générer une adresse d'accès externe. Vous pouvez saisir n'importe quel nom de votre choix.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Une fois la génération terminée, il suffit d'ouvrir cette adresse dans votre navigateur pour jouer à votre propre jeu de serpent. Les autres applications web de type HTML peuvent être déployées exactement de la même manière.
|
||||
|
||||
|
||||
|
||||
### Implémentation avec le framework React
|
||||
|
||||
Précédemment, nous avons appris à déployer des applications web basées sur HTML. Ensuite, essayons de déployer une application utilisant un framework frontend plus courant : React. Comparé au HTML pur, React est considéré comme un framework de développement frontend plus mature et moderne. Il organise la structure des pages de manière componentisée, accélérant significativement le développement de pages complexes. C'est un choix très mainstream dans les projets de niveau entreprise.
|
||||
|
||||
|
||||
|
||||
#### Refactoriser en architecture React
|
||||
|
||||
Dans Trae, il vous suffit de dire à l'Agent : « Aidez-moi à refactoriser ce code en architecture React », pour transformer assez facilement la structure basée sur HTML en un projet React.
|
||||
|
||||
|
||||
|
||||
Cependant, comparé à de simples fichiers HTML, les applications React dépendent d'outils de build et de structures de projet plus complexes, ce qui rend le processus de déploiement un peu plus compliqué. Un problème typique concerne la configuration des ports : par défaut, une application React écoute généralement le port 3000 (vous pouvez le voir dans les fichiers de configuration ou les journaux de démarrage).
|
||||
|
||||
Cependant, un tel déploiement échouera sur Zeabur — car Zeabur ne supporte que les applications qui écoutent le port 8080. Autrement dit, pour que l'application React fonctionne correctement sur Zeabur, nous devons d'abord changer le port d'écoute par défaut de 3000 à 8080.
|
||||
|
||||
Pour effectuer correctement cette configuration, nous devons d'abord clarifier deux concepts : qu'est-ce qu'un « port (Port) », et que signifie « port d'écoute (Listening Port) ».
|
||||
|
||||
#### Qu'est-ce qu'un port ?
|
||||
|
||||
> En informatique réseau, un port peut être compris comme un « point de communication logique » servant à distinguer les différents services réseau s'exécutant sur un même appareil. Pour faire une analogie simple, si l'adresse IP est comme un « numéro de rue » (par exemple 162.128.1.1), alors le numéro de port est comme le « numéro de chambre » des différents locaux dans cet immeuble — chaque chambre correspond à un service (par exemple un serveur web, un service de messagerie, ou votre application React).
|
||||
>
|
||||
> Le numéro de port est représenté par un entier 16 bits, avec une plage de valeurs de 0 à 65535.
|
||||
|
||||
Si vous ne souhaitez pas retenir ces détails, retenez simplement : le port est une partie nécessaire de la constitution d'une « adresse d'accès réseau ».
|
||||
|
||||
Quand nous accédons à des sites web ou des adresses IP, nous ne saisissons généralement pas manuellement le numéro de port, car le port par défaut du web est 80 ou 443 (HTTPS). La plupart des navigateurs utilisent automatiquement ces ports standards. Pour certains ports spéciaux, comme le port 3000 par défaut de React ou le port 8080 requis par Zeabur, nous devons ajouter `:3000` ou `:8080` après l'adresse pour accéder au contenu correspondant.
|
||||
|
||||
#### Qu'est-ce que le « port d'écoute » ?
|
||||
|
||||
> Le « port d'écoute » désigne le port qu'un programme « ouvre et surveille » activement sur un appareil. Quand une application définit un port d'écoute, elle indique en fait au système d'exploitation : « Je vais attendre des requêtes réseau sur ce port en permanence — dès qu'une requête arrive, transférez-la-moi. »
|
||||
|
||||
Pour comprendre de manière plus imagée : imaginez que votre ordinateur est un immeuble de bureaux, l'adresse IP est l'adresse de cet immeuble. L'immeuble abrite de nombreuses entreprises ou départements, occupant différentes chambres, dont les numéros sont les numéros de port.
|
||||
|
||||
Quand le serveur de développement React par défaut démarre, il « ouvre » la porte d'une chambre et y place une « réception » — le numéro de cette chambre est son port d'écoute : 3000.
|
||||
|
||||
Parallèlement, le programme React indique à la « gestion de l'immeuble » (le système d'exploitation) : « Je suis dans la chambre 3000, veuillez me transférer tout le courrier (requêtes réseau) adressé au 3000. »
|
||||
|
||||
Ainsi, quand vous accédez au site React, la requête arrive d'abord à l'immeuble ; la gestion voit que la requête est destinée à la chambre 3000 et la transmet immédiatement à la « réception » de React, qui la traite et renvoie le résultat — c'est le processus d'accès à l'application React.
|
||||
|
||||
Quand vous exécutez `npm start` localement (commande par défaut pour démarrer le serveur de développement React, également exécutable depuis la barre latérale de l'Agent Vibe Coding), le serveur de développement React définit automatiquement le port d'écoute sur 3000.
|
||||
Or, la conception de la plateforme Zeabur fait qu'elle ne « reconnaît » que les applications écoutant le port 8080. Si votre application React utilise toujours le port 3000 par défaut, Zeabur ne pourra pas transférer correctement les requêtes vers votre application, ce qui entraînera l'échec du déploiement.
|
||||
|
||||
#### Modifier le port d'écoute par défaut
|
||||
|
||||
Pour remplacer le port d'écoute par défaut de React (3000) par le port 8080 requis par Zeabur, il existe plusieurs méthodes. La plus simple est de donner directement cette instruction à l'Agent dans Trae : « Aidez-moi à changer le port par défaut de ce projet React en 8080. » Trae modifiera les fichiers de configuration correspondants dans le projet. Une fois la modification effectuée, il vous suffit de reconstruire le projet et de l'uploader sur Zeabur comme précédemment.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dans les paramètres réseau, spécifiez une URL d'accès, de la même manière que pour le déploiement d'un projet HTML, et vous pourrez lancer la version React du service.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Pour les autres programmes nécessitant une modification du numéro de port, vous pouvez adopter la même approche : modifier d'abord le port par défaut, puis uploader sur Zeabur pour le déploiement. Vous maîtrisez désormais les compétences de base pour déployer des applications web courantes sur un serveur.
|
||||
|
||||
Vous pouvez essayer de faire construire par Trae différents types d'applications et les déployer sur le serveur par défaut de Zeabur. Dans les cours suivants, nous apprendrons également comment déployer des applications sur des serveurs cloud que vous avez achetés vous-même.
|
||||
|
||||
---
|
||||
|
||||
# Comment arrêter et supprimer un projet (Zeabur)
|
||||
|
||||
Étant donné que l'activation des ressources liées aux serveurs génère des coûts, il est important de prendre l'habitude de « fermer les services inutilisés en temps opportun » pour éviter d'épuiser votre quota gratuit mensuel.
|
||||
|
||||
Pour trouver l'interface de gestion du projet, cliquez d'abord sur l'option « Settings » du projet.
|
||||
|
||||
|
||||
|
||||
Sur la page des paramètres, faites défiler jusqu'en bas et vous verrez une interface similaire à celle-ci :
|
||||
|
||||
|
||||
|
||||
Vous pouvez cliquer sur « Suspend All Services » pour suspendre tous les services et réduire les coûts ; si un service rencontre un problème, vous pouvez cliquer sur « Restart All Services » pour redémarrer tous les services. Si vous êtes sûr de ne plus avoir besoin de ce projet, vous pouvez cliquer sur « Delete Project » pour le supprimer définitivement.
|
||||
|
||||
---
|
||||
|
||||
# Résumé
|
||||
|
||||
Dans ce tutoriel, nous avons présenté quatre plateformes de déploiement d'applications web courantes :
|
||||
|
||||
1. **Tencent CloudBase** : adapté aux utilisateurs en Chine, accès rapide, bonne intégration avec l'écosystème WeChat
|
||||
2. **Vercel** : adapté aux projets utilisant des frameworks frontend modernes, intégration étroite avec GitHub, accélération CDN mondiale
|
||||
3. **Netlify** : fonctionnalités complètes, support du traitement de formulaires et de l'authentification, adapté aux sites statiques nécessitant des fonctionnalités avancées
|
||||
4. **Zeabur** : adapté aux projets complexes, templates de services riches, support de multiples méthodes de déploiement
|
||||
|
||||
Le choix de la plateforme dépend de vos besoins spécifiques :
|
||||
- Si vous ciblez principalement les utilisateurs en Chine, recommandez **CloudBase**
|
||||
- Si vous utilisez des frameworks comme React/Next.js, recommandez **Vercel** ou **Netlify**
|
||||
- Si vous avez besoin de fonctionnalités avancées comme le traitement de formulaires, l'authentification, recommandez **Netlify**
|
||||
- Si vous devez déployer des services comme Dify, n8n, recommandez **Zeabur**
|
||||
|
||||
Quel que soit le choix de la plateforme, le processus principal de déploiement est similaire : préparer le code -> choisir la plateforme -> configurer les paramètres de build -> déployer en ligne. Une fois ces compétences maîtrisées, vous pourrez partager vos applications développées avec le monde entier !
|
||||
@@ -0,0 +1,362 @@
|
||||
# Du prototype de conception au code de projet
|
||||
|
||||
::: tip 🎯 Question centrale
|
||||
**Comment transformer les prototypes des outils de conception en code frontend véritablement exécutable dans un navigateur ?**
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. Trois chemins du prototype au code
|
||||
|
||||
Après avoir terminé la conception d'interface avec des outils de conception frontend modernes comme Figma ou MasterGo, une question très pratique se pose naturellement : comment convertir ces maquettes structurellement complètes en code frontend véritablement exécutable dans un navigateur ?
|
||||
|
||||
En général, la transformation du prototype en code suit trois chemins typiques :
|
||||
|
||||
| Chemin | Méthode | Caractéristiques | Scénario applicable |
|
||||
|------|------|------|------|
|
||||
| **Chemin 1** | Utiliser un grand modèle multimodal pour restaurer le code à partir d'une image | Flexible, ne nécessite pas d'outil spécifique | Validation rapide de prototype, pages simples |
|
||||
| **Chemin 2** | Exporter le code via les capacités propres de la plateforme ou des plugins | Haute fidélité de restitution, forte éditable | Utilisateurs Figma/MasterGo |
|
||||
| **Chemin 3** | Combiner la plateforme avec les capacités MCP pour exporter le code | Haut degré d'automatisation, personnalisable | Flux de travail nécessitant une intégration approfondie |
|
||||
|
||||
Cet article présentera en détail les méthodes de mise en œuvre de ces trois chemins, pour vous aider à choisir le flux de travail le plus adapté selon les besoins de votre projet.
|
||||
|
||||
::: tip 📚 Prérequis
|
||||
Avant de commencer cette section, il est recommandé d'avoir étudié le tutoriel [Introduction à Figma et MasterGo](../figma-mastergo/), afin de maîtriser les opérations de base des outils de conception frontend.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 2. Chemin 1 : Restauration directe du code par IA multimodale
|
||||
|
||||
Les grands modèles dotés de capacités visuelles possèdent nativement la capacité de convertir des images en code. Il suffit d'importer directement la capture de la maquette dans la boîte de dialogue, puis de demander au grand modèle de générer le code complet du résultat.
|
||||
|
||||
### 2.1 Processus opérationnel
|
||||
|
||||
1. **Capturer l'image de la maquette**
|
||||
- Dans Figma ou MasterGo, exportez la page conçue au format PNG ou JPG
|
||||
- Assurez-vous que la capture contient la mise en page complète de la page
|
||||
|
||||
2. **Choisir un modèle IA multimodal**
|
||||
- Vous pouvez utiliser Gemini, Qwen, Claude et d'autres modèles prenant en charge l'entrée d'image
|
||||
- Nous utiliserons Gemini pour la démonstration
|
||||
|
||||
3. **Rédiger le prompt**
|
||||
```
|
||||
Veuillez générer le code HTML/CSS correspondant à partir de cette maquette de conception.
|
||||
Exigences :
|
||||
- Utiliser une mise en page CSS moderne (Flexbox/Grid)
|
||||
- Design responsive, adapté aux différentes tailles d'écran
|
||||
- Inclure tous les éléments UI visibles
|
||||
- Couleurs et tailles de police fidèles à la maquette autant que possible
|
||||
```
|
||||
|
||||
|
||||
|
||||
4. **Obtenir et sauvegarder le code**
|
||||
- Demander au modèle de retourner le code HTML complet
|
||||
- Sauvegarder sous un seul fichier `.html` pour faciliter les tests locaux
|
||||
- Vous pouvez ensuite le convertir en React ou d'autres frameworks dans votre IDE local
|
||||
|
||||
### 2.2 Problèmes courants et solutions
|
||||
|
||||
La génération de pages n'est pas une tâche simple. Vous pourriez rencontrer de nombreux problèmes au cours du processus :
|
||||
|
||||
| Problème | Solution |
|
||||
|------|----------|
|
||||
| Disposition inégale de l'interface | Décrire à l'IA le problème de mise en page spécifique, demander d'ajuster le margin/padding du CSS |
|
||||
| Affichage incomplet de l'interface | Vérifier si le viewport est correctement défini, demander d'ajouter des points de rupture responsive |
|
||||
| Fidélité des couleurs imprécise | Utiliser un outil de pipette pour obtenir les valeurs de couleur exactes de la maquette et les fournir à l'IA |
|
||||
| Police non correspondante | Spécifier le nom exact de la police ou demander d'utiliser Google Fonts comme substitut |
|
||||
|
||||
::: tip 💡 Astuce
|
||||
Il est recommandé de générer d'abord le code HTML, puis de l'importer dans votre IDE local pour le convertir en framework React. Vous obtiendrez ainsi plusieurs fichiers HTML indépendants, faciles à convertir uniformément en framework.
|
||||
:::
|
||||
|
||||
### 2.3 MasterGo AI pour la génération de pages
|
||||
|
||||
MasterGo offre également une puissante fonctionnalité de génération de pages par IA, capable de générer directement du code web exploitable à partir d'images de référence.
|
||||
|
||||
#### Trouver l'entrée de la fonctionnalité IA
|
||||
|
||||
Dans la barre d'outils supérieure de l'interface d'édition MasterGo, vous trouverez le bouton d'outil IA :
|
||||
|
||||
|
||||
|
||||
#### Processus de génération
|
||||
|
||||
1. **Télécharger une image de référence**
|
||||
- Téléchargez l'image de référence de conception de la même manière que pour l'IA multimodale
|
||||
- Ajoutez une description textuelle des besoins
|
||||
|
||||
2. **Consulter le résultat de la génération**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. **Obtenir le code**
|
||||
- Cliquez sur le bouton bleu « Insérer dans le canevas » pour éditer directement la page web générée
|
||||
- Ou cliquez sur le bouton « Code » à droite pour copier le contenu du code en local
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 3. Chemin 2 : Capacités de la plateforme ou plugins pour exporter le code
|
||||
|
||||
### 3.1 Figma Make pour la génération de code
|
||||
|
||||
Figma Make est un outil de conception IA officiellement lancé par Figma, capable de restaurer avec haute précision l'interface UI d'un prototype web à partir de prompts ou d'images de référence saisis par l'utilisateur.
|
||||
|
||||
#### Caractéristiques fonctionnelles
|
||||
|
||||
- **Restauration haute précision** : par rapport à la génération de code par IA native, l'effet est meilleur
|
||||
- **Éditable** : le résultat généré peut être converti en fichier Figma Design modifiable
|
||||
- **Intégration GitHub** : supporte la synchronisation directe du code vers GitHub
|
||||
|
||||
::: tip 🔑 Note sur les permissions
|
||||
L'utilisation complète de Figma Make nécessite les permissions utilisateur Pro. Les étudiants peuvent obtenir gratuitement les permissions Pro via la certification éducation.
|
||||
:::
|
||||
|
||||
#### Étapes opérationnelles
|
||||
|
||||
1. **Accéder à Figma Make**
|
||||
- Cliquez sur le bouton Make sur la page d'accueil de Figma
|
||||
- Ou visitez [Figma Make](https://www.figma.com/make)
|
||||
|
||||
2. **Télécharger une image de référence**
|
||||
- Téléchargez l'image de conception que vous souhaitez restaurer dans la boîte de dialogue
|
||||
- Ajoutez un prompt décrivant les besoins
|
||||
|
||||
|
||||
|
||||
3. **Consulter le résultat de la génération**
|
||||
- Attendez quelques instants pour voir le résultat rendu
|
||||
- Cliquez sur le bouton de lecture en haut à droite pour un aperçu plein écran
|
||||
|
||||
|
||||
|
||||
4. **Ajustements de détail**
|
||||
- Cliquez sur l'icône de l'éditeur en haut à droite (icône souris et règle)
|
||||
- Retournez dans l'interface familière de Figma Editor pour des ajustements détaillés
|
||||
|
||||
|
||||
|
||||
5. **Exporter le code**
|
||||
- Après être satisfait des ajustements, sélectionnez l'export de code
|
||||
- Vous pouvez vous connecter directement à GitHub pour sauvegarder le code
|
||||
|
||||
|
||||
|
||||
### 3.2 Export de code via plugins
|
||||
|
||||
Outre les fonctionnalités IA natives de la plateforme, Figma et MasterGo supportent tous deux l'export de code via des plugins :
|
||||
|
||||
**Plugins Figma courants :**
|
||||
- **Figma to Code** : convertit les maquettes en code React, Vue, HTML, etc.
|
||||
- **Anima** : génération de code haute fidélité, supporte les effets d'interaction
|
||||
- **Locofy** : outil de conversion design vers code piloté par IA
|
||||
|
||||
**Étapes d'utilisation :**
|
||||
1. Ouvrez le panneau des plugins dans Figma (Plugins)
|
||||
2. Recherchez et installez le plugin d'export de code souhaité
|
||||
3. Sélectionnez les éléments de conception à exporter
|
||||
4. Exécutez le plugin, choisissez le framework cible et le format de code
|
||||
5. Copiez ou téléchargez le code généré
|
||||
|
||||
---
|
||||
|
||||
## 4. Chemin 3 : Combiner la plateforme avec MCP pour exporter le code
|
||||
|
||||
### 4.1 Qu'est-ce que MCP ?
|
||||
|
||||
MCP (Model Context Protocol, Protocole de Contexte de Modèle) est un protocole standard ouvert qui permet aux modèles IA d'accéder de manière sécurisée et contrôlée à des outils externes et des sources de données. Dans le contexte des outils de conception frontend, MCP permet aux grands modèles de lire directement la structure, les styles et les informations de composants des fichiers de conception, pour générer du code plus précis.
|
||||
|
||||
### 4.2 Principe de fonctionnement de MCP
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ Modèle IA │ ←→ │ Serveur MCP │ ←→ │ Outil de │
|
||||
│ (Claude etc)│ │ (adaptation) │ │ conception │
|
||||
│ │ │ protocole │ │(Figma/MasterGo)│
|
||||
└─────────────┘ └─────────────┘ └─────────────┘
|
||||
```
|
||||
|
||||
**Flux de travail :**
|
||||
1. Le modèle IA envoie une requête à l'outil de conception via le protocole MCP
|
||||
2. L'outil de conception retourne des données de conception structurées (calques, styles, composants, etc.)
|
||||
3. Le modèle IA comprend la structure de conception et génère le code correspondant
|
||||
4. Le code peut être directement exporté ou synchronisé vers l'environnement de développement
|
||||
|
||||
### 4.3 Figma + MCP en pratique
|
||||
|
||||
#### Préparation de l'environnement
|
||||
|
||||
1. **Installer le serveur MCP**
|
||||
```bash
|
||||
# Installer le serveur Figma MCP via npx
|
||||
npx figma-mcp-server
|
||||
```
|
||||
|
||||
2. **Configurer Claude Desktop ou un autre outil IA supportant MCP**
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"figma": {
|
||||
"command": "npx",
|
||||
"args": ["figma-mcp-server"],
|
||||
"env": {
|
||||
"FIGMA_ACCESS_TOKEN": "your-figma-token"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
3. **Obtenir un Figma Access Token**
|
||||
- Connectez-vous à Figma → Settings → Personal Access Tokens
|
||||
- Générez un nouveau Token et sauvegardez-le
|
||||
|
||||
#### Flux d'utilisation
|
||||
|
||||
1. **Activer la connexion MCP dans l'outil IA**
|
||||
- Ouvrez Claude Code ou un autre IDE supportant MCP
|
||||
- Confirmez que le serveur MCP est connecté
|
||||
|
||||
2. **Fournir le lien du fichier de conception**
|
||||
```
|
||||
Utilisateur : Aidez-moi à convertir ce design Figma en code React
|
||||
Lien : https://www.figma.com/file/xxxxx
|
||||
|
||||
IA : Je me suis connecté à Figma via MCP, lecture de la structure du fichier de conception en cours...
|
||||
```
|
||||
|
||||
3. **L'IA analyse et génère automatiquement le code**
|
||||
- Le serveur MCP récupère l'arbre de calques du fichier de conception
|
||||
- L'IA comprend la structure des composants et les propriétés de style
|
||||
- Génère des composants React/Vue avec un nommage et une structure corrects
|
||||
|
||||
4. **Itération et optimisation**
|
||||
```
|
||||
Utilisateur : Veuillez extraire le composant bouton en un composant réutilisable indépendant
|
||||
|
||||
IA : D'accord, j'ai identifié via MCP le composant Button dans le système de conception,
|
||||
génération en cours d'un composant React avec interface props...
|
||||
```
|
||||
|
||||
### 4.4 Avantages de MCP
|
||||
|
||||
| Caractéristique | Approche traditionnelle | Approche MCP |
|
||||
|------|----------|----------|
|
||||
| **Précision des données** | Dépend des captures, détails potentiellement perdus | Lecture directe des données de conception brutes |
|
||||
| **Identification des composants** | L'IA doit deviner les limites des composants | Obtention précise des définitions de composants |
|
||||
| **Fidélité des styles** | Estimation basée sur les pixels | Obtention des tokens de conception exacts |
|
||||
| **Efficacité d'itération** | Chaque modification nécessite une nouvelle capture | Synchronisation en temps réel des changements de conception |
|
||||
| **Degré d'automatisation** | Copier-coller manuel | Écriture directe possible dans les fichiers du projet |
|
||||
|
||||
### 4.5 Outils MCP actuellement disponibles
|
||||
|
||||
**MCP pour outils de conception :**
|
||||
- **Figma MCP Server** : implémentation MCP officiellement supportée
|
||||
- **MasterGo MCP** : adaptateur MasterGo développé par la communauté
|
||||
|
||||
**MCP pour environnements de développement :**
|
||||
- **Claude Code** : support natif du protocole MCP
|
||||
- **Cline** : plugin VS Code, supporte les connexions MCP
|
||||
- **Trae** : peut activer les fonctionnalités MCP via configuration
|
||||
|
||||
::: tip 🔮 Perspectives futures
|
||||
Le protocole MCP évolue rapidement, et l'intégration entre outils de conception et environnements de développement deviendra encore plus étroite. D'autres solutions de synchronisation en un clic du design vers le code devraient apparaître, réduisant encore davantage la distance entre conception et développement.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 5. Travail après l'export du code
|
||||
|
||||
### 5.1 Tests locaux
|
||||
|
||||
Après avoir obtenu le code, ouvrez-le dans votre IDE local et testez-le :
|
||||
|
||||
1. **Créer un nouveau projet**
|
||||
```bash
|
||||
# Si c'est un fichier HTML, ouvrez-le directement dans le navigateur
|
||||
open index.html
|
||||
|
||||
# Si c'est un projet React/Vue
|
||||
npm install
|
||||
npm run dev
|
||||
```
|
||||
|
||||
2. **Collaborer avec un IDE IA**
|
||||
- Importez le code généré dans Trae ou un autre IDE IA
|
||||
- Laissez l'IA vous aider à corriger les problèmes de mise en page et à ajouter des fonctionnalités interactives
|
||||
|
||||
### 5.2 Traitement des problèmes courants
|
||||
|
||||
| Étape | Problème | Solution |
|
||||
|------|------|----------|
|
||||
| Mise en page | Éléments décalés | Vérifier les propriétés CSS display et position |
|
||||
| Styles | Couleurs incohérentes | Utiliser les outils de développement du navigateur pour vérifier les couleurs réellement appliquées |
|
||||
| Responsive | Affichage anormal sur mobile | Ajouter des points de rupture media query |
|
||||
| Interaction | Boutons sans réponse | Vérifier la liaison des événements JavaScript |
|
||||
|
||||
---
|
||||
|
||||
## 6. Comparaison des trois chemins et recommandations
|
||||
|
||||
### 6.1 Comparaison des chemins
|
||||
|
||||
| Dimension | Chemin 1 : IA multimodale | Chemin 2 : Capacités plateforme | Chemin 3 : MCP |
|
||||
|------|------------------|------------------|-------------|
|
||||
| **Difficulté de prise en main** | ⭐ Simple | ⭐⭐ Moyen | ⭐⭐⭐ Assez complexe |
|
||||
| **Précision de restitution** | ⭐⭐⭐ Moyenne | ⭐⭐⭐⭐ Élevée | ⭐⭐⭐⭐⭐ Maximale |
|
||||
| **Flexibilité** | ⭐⭐⭐⭐⭐ Élevée | ⭐⭐⭐ Moyenne | ⭐⭐⭐⭐ Assez élevée |
|
||||
| **Degré d'automatisation** | ⭐⭐ Faible | ⭐⭐⭐ Moyen | ⭐⭐⭐⭐⭐ Maximale |
|
||||
| **Coût** | Faible (facturation à l'usage API) | Moyen (peut nécessiter Pro) | Faible (outils open source) |
|
||||
|
||||
### 6.2 Recommandations
|
||||
|
||||
**Choisir le Chemin 1 (IA multimodale) si :**
|
||||
- Vous avez besoin de valider rapidement une idée
|
||||
- L'outil de conception n'est pas fixe, vous changez souvent
|
||||
- Les exigences de fidélité de restitution ne sont pas très élevées
|
||||
- Le budget est limité
|
||||
|
||||
**Choisir le Chemin 2 (capacités plateforme) si :**
|
||||
- L'équipe utilise principalement Figma ou MasterGo
|
||||
- Une restitution de code haute précision est nécessaire
|
||||
- Les designers et développeurs doivent collaborer fréquemment
|
||||
- Vous êtes prêt à investir dans une version Pro
|
||||
|
||||
**Choisir le Chemin 3 (MCP) si :**
|
||||
- Vous visez le plus haut degré d'automatisation
|
||||
- Vous avez les compétences techniques pour configurer l'environnement MCP
|
||||
- Le projet nécessite des itérations fréquentes du design vers le code
|
||||
- Vous souhaitez établir un flux de travail standardisé design-développement
|
||||
|
||||
---
|
||||
|
||||
## 7. Résumé
|
||||
|
||||
Au cours de ce chapitre, vous avez maîtrisé les trois chemins clés du prototype de conception au code :
|
||||
|
||||
1. **Conversion directe par IA multimodale** : flexible et rapide, adaptée à la validation de prototypes
|
||||
2. **Capacités natives de la plateforme** : haute fidélité, adaptée aux flux de travail de conception professionnels
|
||||
3. **Intégration du protocole MCP** : degré d'automatisation le plus élevé, représente la tendance future
|
||||
|
||||
::: tip 💡 Meilleures pratiques
|
||||
- **Recommandation pour les débutants** : commencer par le Chemin 1 (IA multimodale) pour une prise en main rapide
|
||||
- **Collaboration en équipe** : utiliser le Chemin 2 (capacités plateforme) pour garantir la cohérence du design
|
||||
- **Priorité à l'efficacité** : essayer le Chemin 3 (MCP) pour établir un flux de travail automatisé
|
||||
- **Utilisation mixte** : basculer flexiquement entre les différents chemins selon la phase du projet
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Ressources de référence
|
||||
|
||||
- [Introduction à Figma et MasterGo](../figma-mastergo/) - Apprendre les bases des outils de conception
|
||||
- [Créons ensemble des portraits de Poudlard](../hogwarts-portraits/) - Projet pratique complet
|
||||
- [Documentation officielle MCP](https://modelcontextprotocol.io/) - Comprendre les détails du protocole
|
||||
- [Documentation officielle Figma Make](https://help.figma.com/hc/en-us/sections/360007453634-Figma-Make)
|
||||
- [Tutoriels MasterGo AI](https://mastergo.com/tutorials)
|
||||
@@ -0,0 +1,303 @@
|
||||
# Introduction à Figma et MasterGo
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const relatedArticles = relatedArticlesMap['zh-cn/stage-2/frontend/figma-mastergo'] ?? []
|
||||
</script>
|
||||
|
||||
::: tip 🎯 Question centrale
|
||||
**Comment créer un prototype de page web depuis zéro avec des outils de conception modernes ?**
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. Pourquoi apprendre les outils de conception frontend ?
|
||||
|
||||
Avant de commencer, nous devons comprendre une question : pourquoi a-t-on besoin d'apprendre des « outils de conception frontend » ? Après tout, on peut très bien construire des pages directement en HTML/CSS, alors est-ce vraiment nécessaire d'apprendre un logiciel et une technologie supplémentaires ?
|
||||
|
||||
En réalité, faire fonctionner une page et bien concevoir un produit sont deux concepts totalement différents. Le code se préoccupe uniquement de comment rendre dans le navigateur et comment s'exécuter sur différents appareils ; les outils de conception frontend résolvent les problèmes de distribution de l'information : comment organiser les interactions frontend, comment gérer la navigation entre les pages, comment hiérarchiser les priorités visuelles. Il suffit de créer un canevas dans l'outil de conception pour comparer et déterminer la mise en page, la hiérarchie d'information et les modes d'interaction sur un seul écran, afin de choisir la présentation la plus appropriée.
|
||||
|
||||
Si l'on commence directement à coder ou si l'on demande à l'IA de générer des pages frontend complètes, l'expérience utilisateur ne sera généralement pas très bonne. Les produits rigoureux prennent en compte le confort de l'interaction utilisateur-frontend ainsi que la répartition du contenu à transmettre sur les différentes pages. En concevant d'abord la mise en page du point de vue de l'utilisateur, puis en procédant à la conversion ou à la génération de code.
|
||||
|
||||
De plus, du point de vue de la collaboration en équipe, les outils de conception frontend réduisent également les coûts de coopération entre les différentes parties : designers, chefs de produit et développeurs ne se retrouvent plus chacun face à des images mentales ou des descriptions de code abstraites. Ils supportent la collaboration en temps réel, permettant à tous de discuter de la gestion des versions, des changements de besoins et des retours autour d'un canevas visible, annotable et itérable. Plus encore, les outils de conception frontend modernes ne se contentent plus d'être des logiciels de dessin : génération partielle de code en un clic, gestion de systèmes de conception et de bibliothèques de composants. Les outils de conception de nouvelle génération peuvent automatiser ou traiter par lots une grande partie du travail répétitif (alignement, annotation, exportation, modification de styles), améliorant considérablement l'efficacité du développement de la conception de pages.
|
||||
|
||||
|
||||
|
||||
### 1.1 L'évolution des outils de conception frontend
|
||||
|
||||
Au fil du temps, les outils dits de conception frontend représentent en réalité une technologie en constante évolution. De l'ère Photoshop des années 90, centrée sur l'édition d'images bitmap locales, à Sketch qui a apporté les flux de travail vectoriels et componentisés vers 2010, puis à Figma qui a définitivement déplacé la collaboration vers le cloud après 2016. Les équipes de conception sont progressivement passées du travail individuel à la collaboration en temps réel. En 2025, l'IA est désormais intégrée de manière concrète dans ces outils : de la « génération de maquettes de page à partir d'une phrase » à la « conversion directe de maquettes en structures frontend exécutables », le « design as code » et la « co-création homme-machine » passent du concept à une véritable productivité.
|
||||
|
||||
Dans cette section, nous présenterons les deux outils de conception frontend modernes les plus représentatifs : Figma et MasterGo. D'une part, ils couvrent tous les deux les capacités clés nécessaires à l'UI/UX moderne (édition vectorielle, système de composants, mise en page automatique, livraison de code, etc.), et peuvent vous accompagner dans le cycle complet, du wireframe au haute fidélité jusqu'à la livraison au développement. D'autre part, ces deux outils ont progressivement intégré des fonctionnalités IA pratiques après 2025, vous aidant à transformer vos maquettes en véritables programmes exécutables tout en préservant le prototype intact.
|
||||
|
||||
## 1.2 Le voyage de la création
|
||||
|
||||
|
||||
|
||||
À l'époque où les outils dédiés au frontend n'existaient pas encore, le travail de conception visuelle de toute l'industrie du design d'interface était, pendant très longtemps, assuré par des logiciels de conception « polyvalents » comme Photoshop. Les designers créaient localement, par superposition de calques, la conception visuelle globale de la page, puis livraient le fichier source .psd, souvent volumineux, à l'ingénieur frontend — qui devait alors accomplir manuellement trois tâches fastidieuses mais cruciales pour reproduire fidèlement la maquette :
|
||||
|
||||
Premièrement, le « découpage d'images » : il fallait extraire un par un les éléments visuels indépendants (boutons, icônes, logos, modules d'arrière-plan, etc.) de la structure multicouche du fichier .psd, puis les exporter dans des formats d'image directement chargeables par le web comme PNG ou JPG (puisque le web ne peut pas identifier directement les informations de calques PSD, il ne peut s'appuyer que sur ces images découpées pour afficher les détails).
|
||||
|
||||
|
||||
|
||||
Deuxièmement, le « mesurage des dimensions » : il fallait utiliser l'outil de mesure du logiciel pour vérifier逐一 la largeur, la hauteur et les espacements (margin/padding) entre différents modules, afin de garantir que toutes les dimensions soient précises au pixel près.
|
||||
|
||||
|
||||
|
||||
Troisièmement, l'« extraction des annotations » : il fallait extraire de la maquette les paramètres invisibles mais indispensables — comme la taille de police, le poids, l'interligne, les valeurs de couleur RGB ou HEX de chaque bloc de couleur, etc. Cela équivalait à extraire et consigner manuellement les « spécifications de conception » que le designer n'avait pas écrites sur papier.
|
||||
|
||||
|
||||
|
||||
Ce n'est qu'après ces étapes que la phase d'implémentation frontend pouvait véritablement commencer. Que l'on utilise du HTML/CSS/JS natif ou des frameworks comme Vue ou React, le processus fondamental est le même. Le frontend utilise le « conteneur comme support central », reconstruisant la structure de la page selon la hiérarchie et la sémantique des différents modules du design. Ici, le conteneur désigne une unité avec des limites de mise en page clairement définies, dédiée à l'accueil et à l'organisation des éléments enfants. Il n'affiche pas directement le contenu, mais délimite la plage d'arrangement des éléments internes via des règles comme Flex ou Grid. Les « blocs structurels » (comme la barre de navigation supérieure, la barre latérale, la zone de liste d'articles, le pied de page, etc. — zones fonctionnelles/contenus visibles) s'appuient sur les conteneurs ; chaque bloc structurel imbrique à son tour des conteneurs plus petits pour organiser les éléments. Par exemple, un élément de liste d'articles sera contrôlé par un « conteneur d'élément de liste » qui gère le remplissage interne et la mise en page d'ensemble, puis enveloppe les détails comme le titre, le résumé, l'heure et l'icône de couverture.
|
||||
|
||||
|
||||
|
||||
Dans les frameworks frontend modernes, ces « blocs structurels (et les conteneurs et éléments associés) » sont généralement implémentés sous forme de « composants ». Un composant peut être simplement compris comme une unité d'interface réutilisable avec des limites claires, intégrant la mise en page des conteneurs et la logique. Il contient à la fois les conteneurs qui contrôlent l'apparence et l'arrangement (par exemple, le « composant bouton » définit la largeur, la hauteur et les coins arrondis via le conteneur ; le « composant carte d'article » organise la position du titre et de la couverture via le conteneur) et encapsule la logique d'interaction. Les éléments qui apparaissent de manière répétée dans la maquette avec une apparence cohérente (comme les boutons de style uniforme, les cartes d'articles réutilisées) sont abstraits en composants dans le code : ils peuvent être réutilisés dans différentes pages/scènes, réduisant le développement répétitif, et garantissent une cohérence élevée de mise en page et de style à travers les règles unifiées des conteneurs internes du composant.
|
||||
|
||||
Ensuite, le frontend utilise le système de styles pour reproduire le visuel et la mise en page. Les ressources exportées lors de la phase de découpage d'images (PNG, JPG, etc.) sont intégrées comme `<img>`, images d'arrière-plan dans les composants ou blocs structurels, ou importées selon les méthodes recommandées par chaque framework. Les valeurs spécifiques de largeur, hauteur, espacement et interligne obtenues lors du mesurage sont transcrites en propriétés de style comme `width`, `height`, `margin`, `padding`, `line-height`, appliquées aux composants ou blocs structurels correspondants. Les couleurs, polices, ombres, coins arrondis et états hover/active compilés lors de l'annotation sont quant à eux appliqués via `color`, `font-family`, `font-size`, `box-shadow`, `border-radius` et les pseudo-classes ou classes d'état dans les solutions spécifiques comme CSS, CSS Modules, CSS-in-JS ou Tailwind. À ce stade, le découpage, les dimensions et les annotations fournissent un ensemble de paramètres visuels précis, tandis que les composants et blocs structurels fournissent les unités d'organisation de code pour porter ces paramètres. L'ensemble forme une implémentation d'interface maintenable et réutilisable.
|
||||
|
||||
|
||||
|
||||
Cependant, le modèle centré sur les fichiers locaux est intrinsèquement inefficace. Les versions sont transmises par email et cloud, les anciens et nouveaux fichiers se confondent facilement, et la collaboration entre design et développement repose largement sur les méthodes d'interaction complexes décrites ci-dessus, avec des coûts de coopération et des risques d'erreur non négligeables.
|
||||
|
||||
Avec l'essor du mobile, la complexité des interfaces et les besoins d'itération rapide ont fortement augmenté, et le côté « tout-en-un » de Photoshop est apparu de plus en plus lourd. C'est à cette période qu'est apparu Sketch. Sketch se concentre sur le design UI lui-même, débarrassé de la plupart des contraintes liées au post-traitement visuel. Il utilise les Symbols pour componentiser les éléments très réutilisables comme les boutons, la navigation et les champs de saisie — une seule modification se synchronise globalement. Combiné à des outils comme Zeplin, il génère automatiquement les annotations et les fragments de style. Sketch a introduit la « pensée composant » dans le flux de travail de conception. Cependant, il reste une application de bureau basée sur des fichiers locaux ; la collaboration en temps réel nécessite des contournements via le cloud, des plugins tiers ou des outils de versionning, et ne résout pas fondamentalement le problème de « plusieurs personnes modifiant simultanément le même fichier ».
|
||||
|
||||
|
||||
|
||||
Ce qui a véritablement changé la donne, c'est Figma. Dès 2016, il a intégré le design UI, le prototypage, les commentaires et la collaboration dans le navigateur, avec des fonctionnalités modernes : curseurs multiples en temps réel, commentaires en ligne, timeline de versions, liens de partage, etc. Ce qui semble très simple aujourd'hui représentait à l'époque un défi direct au modèle Photoshop/Sketch.
|
||||
|
||||
|
||||
|
||||
Dès lors, le design d'interface n'est plus constitué de fichiers éparpillés sur les ordinateurs de chacun, mais d'un canevas cloud centralisé, en ligne et mis à jour en temps réel. Autour de ce canevas, on peut imaginer aller encore plus loin, en brouillant les frontières entre design et code frontend via l'automatisation ou l'IA.
|
||||
|
||||
Au tout début, nous ne pouvions nous appuyer que sur divers plugins de plateforme pour exporter de manière semi-automatique les composants et les informations de style des maquettes sous forme de fragments de code (comme des squelettes de composants React/Vue, des variables CSS, etc.). L'essence de cette approche était l'extraction d'informations structurées via des plugins. Ensuite, avec l'évolution des capacités des plateformes, la plupart d'entre elles ont commencé à supporter les fonctionnalités MCP (Model Context Protocol, Protocole de Contexte de Modèle) pour les grands modèles : ce protocole fournit un mécanisme standardisé permettant aux grands modèles d'accéder de manière sécurisée et contrôlée aux fichiers de conception, aux interfaces de plugins et aux métadonnées de projet, facilitant ainsi l'exportation des maquettes en code.
|
||||
|
||||
Plus tard encore, sur la base des plugins et de MCP, l'automatisation du code frontend est passée à un stade de support natif de la déduction directe de la structure de code à partir des maquettes. Nous pouvons désormais générer en un clic dans l'outil de conception le squelette du projet frontend, la hiérarchie des composants, le système de styles et le code correspondant. Cela libère designers et développeurs frontend du travail manuel de transfert des détails de conception, leur permettant de consacrer davantage d'énergie à l'optimisation de l'expérience utilisateur et aux mises à jour itératives des versions fonctionnelles.
|
||||
|
||||
---
|
||||
|
||||
## 2. Introduction à Figma
|
||||
|
||||
Passons maintenant des concepts abstraits à la pratique. Faute de temps, nous n'apprendrons que la logique de base de Figma, afin que même si vous n'avez jamais utilisé d'outil de conception, vous puissiez suivre les exercices. Si vous souhaitez apprendre Figma de manière complète, veuillez consulter les tutoriels officiels détaillés fournis par Figma : https://help.figma.com/hc/en-us/sections/30880632542743-Figma-Design-for-beginners
|
||||
|
||||
Vous pouvez aussi consulter le tutoriel suivant pour construire rapidement un site simple comme un portfolio personnel : https://help.figma.com/hc/en-us/sections/35895585621655-Figma-Sites-collectio
|
||||
|
||||
|
||||
|
||||
Sur la gauche se trouve l'entrée pour la création de projets et la gestion des ressources, et en haut à droite, plusieurs boutons représentent les fonctionnalités courantes de Figma. Parmi eux, Make permet de demander à l'IA de générer d'abord une interface ou une structure approximative à partir d'une phrase, Design est l'espace de travail principal pour dessiner des interfaces web/app, créer des composants et fabriquer des prototypes, FigJam est un tableau blanc d'équipe pour coller des notes, dessiner des flux et mener des discussions préliminaires, Buzz est un outil de production de ressources de marque à grande échelle, utilisé pour générer du contenu en masse afin de maintenir la cohérence de la marque, et Site permet d'organiser ces conceptions en véritables pages web ou sites documentaires accessibles publiquement.
|
||||
|
||||
À première vue, Figma propose de nombreuses fonctionnalités et peut sembler difficile à prendre en main. Mais en réalité, ce type d'outil fonctionnel repose essentiellement sur la pratique : il ne faut pas craindre de faire des erreurs au début, ni chercher à tout réussir du premier coup. Il suffit de commencer à explorer, et avec la pratique, la maîtrise viendra naturellement.
|
||||
|
||||
Dans ce tutoriel, pour une prise en main rapide, nous présenterons brièvement la fonctionnalité Design.
|
||||
|
||||
### 2.1 Créer un nouveau fichier Design
|
||||
|
||||
Depuis la page d'accueil ou l'entrée en haut à droite, sélectionnez **Design** pour créer un nouveau fichier. Vous accéderez à un canevas de conception vide.
|
||||
Cette interface se divise grossièrement en trois zones : à gauche, les pages et calques, pour visualiser et modifier les relations d'appartenance des pages et éléments ; au centre, le canevas, pour visualiser le résultat actuel ; à droite, les propriétés et styles, pour modifier les formes, couleurs et styles spécifiques ; et en bas, une barre d'outils, pour basculer entre les outils, comprenant la sélection, le dessin de formes, la saisie de texte, les commentaires, les plugins, etc. Après avoir sélectionné un outil, vous pouvez appuyer sur la touche Echap pour revenir à l'outil souris par défaut.
|
||||
|
||||
|
||||
|
||||
### 2.2 Créer votre première Frame (planche)
|
||||
|
||||
Avant de placer des éléments, il faut d'abord définir une limite claire pour la page, assumée par la Frame. Vous pouvez sélectionner l'outil Frame dans la barre d'outils inférieure, ou appuyer directement sur la touche F, puis tracer une zone rectangulaire sur le canevas.
|
||||
|
||||
1. Utilisez l'outil Frame dans la barre d'outils inférieure, ou appuyez directement sur `F`.
|
||||
2. Tracez une zone rectangulaire sur le canevas, puis dans la barre de propriétés de droite, modifiez la largeur, par exemple à `1440`, et la hauteur à `900`.
|
||||
3. Dans la barre de calques à gauche, renommez cette Frame, par exemple `My First Page` ou le nom de votre projet.
|
||||
|
||||
Cette Frame est le conteneur de page pour un écran entier. Ensuite, le titre, le texte, les boutons, les images, etc. doivent tous être placés à l'intérieur de cette Frame, et non éparpillés n'importe où sur le canevas. Organiser le contenu autour de la Frame comme limite permet de garder la structure sous contrôle lors des réglages de défilement, de l'adaptation aux différentes tailles d'appareils, de l'export d'écrans et de la création de prototypes.
|
||||
|
||||
|
||||
|
||||
### 2.3 Placer du texte et des éléments simples dans la Frame
|
||||
|
||||
Maintenant que nous avons un conteneur, apprenons à placer les composants les plus basiques, comme le titre, le sous-titre, le bouton et le bloc d'image placeholder.
|
||||
|
||||
1. Sélectionnez l'outil texte (le `T` dans la barre d'outils inférieure), cliquez dans la Frame et saisissez le titre de la page, par exemple : `My Portfolio`.
|
||||
Dans les propriétés de droite, augmentez la taille de police (par exemple 96) et mettez le poids en gras.
|
||||
2. Sous le titre, utilisez à nouveau l'outil texte pour saisir une brève description, par exemple une ou deux phrases expliquant ce que fait la page.
|
||||
La taille de police peut être plus petite, avec un interligne légèrement plus grand pour une lecture plus aérée.
|
||||
3. Dessinez une ébauche de bouton :
|
||||
Avec l'outil rectangle, dessinez un rectangle d'environ `200 × 48` sous le titre, donnez-lui une couleur de remplissage assez visible dans les propriétés de droite, et ajoutez un léger arrondi.
|
||||
|
||||
4. Puis utilisez l'outil texte pour saisir le libellé du bouton au-dessus du rectangle, par exemple `Get Started`. Sélectionnez ensemble le rectangle et le texte, et utilisez les outils d'alignement en haut pour centrer le texte horizontalement et verticalement.
|
||||
5. Sur le côté du bouton ou en dessous, dessinez un grand rectangle gris clair comme « zone d'image placeholder », qui pourra servir plus tard à afficher une image.
|
||||
|
||||
Arrivé à ce stade, vous avez déjà une « maquette de page d'accueil » très rudimentaire mais structurellement complète : un titre, un paragraphe, un bouton et une zone d'affichage principale.
|
||||
|
||||
|
||||
|
||||
### 2.4 Utiliser Auto Layout pour organiser les éléments
|
||||
|
||||
Si tous les éléments sont simplement traînés au hasard, la page deviendra vite chaotique. Un concept très important dans Figma est l'**Auto Layout**, qui permet de transformer un groupe d'éléments en un conteneur avec des règles.
|
||||
|
||||
|
||||
|
||||
Vous pouvez sélectionner les trois éléments « titre principal + sous-titre + bouton », puis cliquer sur **Add Auto layout** dans la barre de propriétés de droite.
|
||||
|
||||
Ces trois éléments seront alors enveloppés dans un conteneur. Vous pouvez ajuster les paramètres dans la barre de droite, et la mise en page des éléments s'adaptera automatiquement :
|
||||
|
||||
- Sont-ils disposés verticalement ou horizontalement.
|
||||
- Quel est l'espacement entre les éléments.
|
||||
- Quelle est la marge interne (padding) entre l'ensemble et les bords du conteneur.
|
||||
|
||||
|
||||
|
||||
De même, l'intérieur du bouton peut aussi utiliser Auto Layout. Nous pouvons obtenir cet effet : lorsque le texte est modifié, la longueur du bouton s'ajuste automatiquement.
|
||||
|
||||
Sélectionnez d'abord le rectangle d'arrière-plan du bouton et le texte du bouton, ajoutez Auto Layout pour que ces deux éléments deviennent un « conteneur bouton ». Ensuite, sélectionnez ce conteneur bouton et réglez la largeur et la hauteur sur **Hug contents**. Ainsi, le texte restera toujours centré dans le bouton, et que le texte soit plus ou moins long, la largeur du bouton s'ajustera automatiquement.
|
||||
|
||||
|
||||
|
||||
### 2.5 Transformer le bouton en composant réutilisable
|
||||
|
||||
Nous allons maintenant apprendre un nouveau concept : les composants. Un composant est un élément qui peut être réutilisé. Par exemple, un bouton : dès que vous pressentez que vous l'utiliserez à nouveau, vous pouvez envisager d'en faire un composant. Partons du bouton avec Auto Layout que nous venons de créer :
|
||||
|
||||
1. Sélectionnez l'ensemble du conteneur bouton.
|
||||
2. Faites un clic droit et choisissez Create component (créer un composant).
|
||||
|
||||
|
||||
Ainsi, ce bouton passe d'un groupe de calques ordinaires à un composant maître. Ensuite, si vous avez besoin d'un bouton du même style dans d'autres pages ou Frames, il vous suffit de le glisser depuis le panneau Assets à gauche.
|
||||
|
||||
|
||||
|
||||
Tous les boutons ainsi utilisés sont des copies synchronisées de ce maître. Lorsque vous modifiez la couleur, les coins arrondis ou l'espacement du maître, toutes les instances se mettent automatiquement à jour.
|
||||
|
||||
|
||||
|
||||
Vous avez maintenant acquis les bases de l'utilisation simple de Figma. Il n'est pas nécessaire de tout comprendre dès le début ; il suffit de suivre ce guide pour créer une première page simple, se familiariser avec ces quelques opérations clés, puis explorer progressivement les capacités supplémentaires des tutoriels officiels. Avec la pratique, la maîtrise viendra.
|
||||
|
||||
---
|
||||
|
||||
## 3. Introduction à MasterGo
|
||||
|
||||
Après avoir compris le flux de travail de base de Figma, découvrons MasterGo. Vous pouvez considérer MasterGo comme la version chinoise de Figma, avec quelques différences sur certaines fonctionnalités. Dans l'ensemble, il reprend une disposition d'interface et une philosophie d'utilisation similaires à Figma : même canevas, arbre de calques et panneau de propriétés, même support des composants, styles, mise en page automatique et collaboration multi-utilisateurs. Pour plus de détails, consultez le tutoriel officiel de MasterGo : https://mastergo.com/tutorials/12?%E5%85%A8%E7%A8%8B%E9%AB%98%E8%83%BD%EF%BC%8CMasterGo%20%E6%9C%80%E5%AE%8C%E6%95%B4%E5%AE%9E%E7%94%A8%E6%95%99%E7%A8%8B%EF%BC%8C%E8%AE%A9%E4%BD%A0%E4%BB%8E%E9%9B%B6%E5%88%B0%E7%B2%BE%E9%80%9A%EF%BC%81
|
||||
|
||||
### 3.1 Créer un nouveau fichier de conception
|
||||
|
||||
1. **Accéder au tableau de bord MasterGo**
|
||||
1. Ouvrez le site officiel de MasterGo et connectez-vous.
|
||||
2. Vous arriverez sur la page d'accueil avec la « liste de fichiers / liste de projets », pour gérer vos fichiers de conception.
|
||||
|
||||
|
||||
2. **Créer un nouveau fichier**
|
||||
1. Cliquez sur le bouton + Fichier de conception en haut à droite, ou choisissez d'importer des fichiers Figma ou autres.
|
||||
2. Après avoir cliqué, vous accéderez à un canevas vide : c'est l'espace de travail de conception de MasterGo.
|
||||
|
||||
3. **Découvrir les zones de base de l'interface**
|
||||
Une fois que vous savez utiliser Figma, l'utilisation de MasterGo est très similaire. L'interface se divise principalement en plusieurs zones :
|
||||
|
||||
|
||||
1. Barre d'outils supérieure : située en haut du canevas, avec à gauche l'emplacement et le nom du fichier, au centre une rangée de boutons d'outils courants (sélection, zone/planche, formes, texte, annotations, commentaires, sélection de plugins et outils IA, etc.), et à droite les membres actuellement en ligne, l'entrée de partage, ainsi que les contrôles de zoom et d'aperçu du canevas.
|
||||
2. Panneau latéral gauche : principalement divisé en calques et ressources. En restant sur l'onglet calques, vous voyez la liste des pages et la structure hiérarchique de tous les calques de la page.
|
||||
3. Zone de canevas centrale : l'espace de travail pour le dessin et la mise en page. Toutes les Frames, composants et graphiques y sont affichés.
|
||||
4. Panneau de propriétés droit : pour visualiser et modifier les propriétés de l'objet sélectionné, comme la taille, la position, l'alignement, le remplissage d'arrière-plan, les bordures, les coins arrondis, etc. Si aucun objet n'est sélectionné, les paramètres du canevas s'affichent, comme la couleur d'arrière-plan, les étiquettes et les options d'export.
|
||||
|
||||
### 3.2 Créer votre première Frame
|
||||
|
||||
Avant de placer des éléments, nous avons besoin d'un conteneur de page pour définir les limites et les dimensions de l'interface. Ce conteneur s'appelle généralement une Frame dans MasterGo.
|
||||
|
||||
**Étapes :**
|
||||
|
||||
1. **Sélectionner l'outil Frame**
|
||||
1. Trouvez l'outil Frame / Planche dans la barre d'outils, puis cliquez pour créer directement le contenu avec les paramètres prédéfinis.
|
||||
2. Ou utilisez le raccourci (généralement `F`, en cas de différence, se référer à l'interface réelle).
|
||||
2. **Tracer une zone rectangulaire sur le canevas**
|
||||
1. Après avoir tracé, vous verrez une zone avec un cadre de sélection.
|
||||
2. Dans le panneau de propriétés de droite, vous pouvez voir la largeur et la hauteur de cette Frame.
|
||||
3. Réglez la largeur, par exemple, à `1440`, et la hauteur à `900` (l'une des tailles courantes pour une page web plein écran).
|
||||
3. **Renommer la Frame**
|
||||
1. Dans le panneau de calques à gauche, trouvez cette Frame.
|
||||
2. Double-cliquez sur le nom et changez-le pour le nom de votre projet, par exemple : `My First Page`, ou tout autre nom de page de votre choix.
|
||||
|
||||
|
||||
|
||||
### 3.3 Créer le contenu de la planche
|
||||
|
||||
Avec le conteneur, en utilisant des méthodes similaires à celles apprises dans Figma, il est facile d'obtenir une page de présentation similaire. (Vous pouvez essayer de copier les éléments textuels de la planche Figma ; l'importation directe par collage des composants texte est prise en charge.)
|
||||
|
||||
|
||||
|
||||
Il est à noter que le comportement de la fonctionnalité Auto Layout est légèrement différent. Dans MasterGo, si vous souhaitez obtenir le même effet que Figma où la longueur du bouton s'adapte à la longueur du texte, vous devez d'abord créer un conteneur ou composant basé sur l'élément rectangulaire correspondant, comme illustré :
|
||||
|
||||
|
||||
|
||||
Après avoir créé le conteneur avec succès, placez le rectangle du bouton et le texte dans le conteneur correspondant côte à côte, puis trouvez le bouton Auto Layout sur la droite pour activer la fonction automatique. Vous obtiendrez ainsi un bouton dont la largeur s'adapte à la longueur du texte.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 3.4 Génération de pages par IA
|
||||
|
||||
|
||||
|
||||
Dans MasterGo, une fonctionnalité intéressante mérite d'être signalée : la génération de pages par IA. Vous pouvez utiliser une phrase ou fournir une image de référence pour générer des composants éditables dans MasterGo et obtenir du code directement utilisable. Vous pouvez saisir vos besoins directement en chinois ou en anglais, et la page retournera un document structuré avec la mise en page correspondant aux besoins. Voici le résultat :
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Une fois la génération du document de conception terminée, cliquez sur commencer la génération, attendez un instant et vous obtiendrez le résultat de la page web réelle :
|
||||
|
||||
|
||||
|
||||
Vous avez alors deux options : cliquer sur le bouton bleu pour insérer directement le résultat dans le canevas, ou cliquer sur la fonction d'aperçu du code pour obtenir directement le code complet de la page actuelle. L'interface de fonctionnement spécifique est la suivante :
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Après avoir inséré le résultat dans le canevas, vous pouvez encore ajuster plus finement la mise en page d'ensemble de la page et les détails des éléments (comme la police, les couleurs, les espacements, etc.) jusqu'à ce que le résultat final corresponde entièrement à vos attentes.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 4. Prochaine étape : du prototype au code
|
||||
|
||||
Dans les sections précédentes, nous avons appris les opérations de base de Figma et MasterGo, et sommes capables de créer des prototypes d'interface structurellement complets. L'étape clé suivante est : **comment transformer ces maquettes en code frontend véritablement exécutable dans un navigateur ?**
|
||||
|
||||
::: tip 📚 Tutoriel suivant
|
||||
Pour une présentation détaillée des méthodes, veuillez consulter [Du prototype de conception au code de projet](../design-to-code/), où vous apprendrez :
|
||||
|
||||
- **Conversion directe par IA multimodale** : envoyer une capture de la maquette à l'IA pour générer directement du code HTML/React
|
||||
- **Figma Make** : utiliser l'outil IA officiel de Figma pour restaurer la conception avec haute précision et exporter le code
|
||||
- **MasterGo AI** : générer en un clic des pages éditables et obtenir le code
|
||||
|
||||
Ces méthodes ont chacune leurs avantages et inconvénients, et s'adaptent à différents scénarios. Il est recommandé de choisir le flux de travail le plus adapté selon les besoins du projet.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 5. Résumé
|
||||
|
||||
Au cours de ce chapitre, vous avez acquis :
|
||||
|
||||
1. **La valeur des outils de conception frontend** : compris pourquoi ces outils sont nécessaires et comment ils résolvent les problèmes de distribution de l'information et de collaboration en équipe.
|
||||
|
||||
2. **Les opérations de base de Figma** :
|
||||
- Créer des fichiers Design et des planches Frame
|
||||
- Ajouter des éléments de base comme le texte et les formes
|
||||
- Utiliser Auto Layout pour des mises en page adaptatives
|
||||
- Créer un système de composants réutilisables
|
||||
|
||||
3. **Les opérations de base de MasterGo** :
|
||||
- Se familiariser avec la disposition d'interface similaire à Figma
|
||||
- Créer des Frames et du contenu de planche basique
|
||||
- Utiliser la fonctionnalité de génération de pages par IA pour créer rapidement des prototypes
|
||||
|
||||
::: tip 💡 Prochaine étape
|
||||
Maintenant que vous maîtrisez les bases des outils de conception frontend, vous pouvez essayer de :
|
||||
- Concevoir une page de portfolio personnel
|
||||
- Concevoir des prototypes d'interface pour vos projets à venir
|
||||
- Apprendre [Du prototype de conception au code de projet](../design-to-code/) pour transformer vos maquettes en code exécutable
|
||||
|
||||
Si vous travaillez sur le projet [Créons ensemble des portraits de Poudlard](../hogwarts-portraits/), vous pouvez d'abord concevoir le prototype d'interface, puis exporter le code pour le combiner avec les fonctionnalités de dialogue IA.
|
||||
:::
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="Articles associés"
|
||||
description="Il est recommandé de poursuivre l'apprentissage de la conception UI avancée et de la pratique de conversion du design en code."
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1,343 @@
|
||||
# Projet 4 : Créons ensemble des Portraits de Poudlard
|
||||
|
||||
Dans les cours précédents, nous avons appris à utiliser le prompt engineering et les appels d'API pour réaliser des interactions AI plus complexes. Nous avons été capables de transformer de simples chatbots AI en Agents AI et workflows AI ; grâce à des conditions et des logiques de branchement plus avancées, nous avons pu développer des fonctionnalités beaucoup plus pratiques.
|
||||
|
||||
Pour que ces logiques AI complexes puissent mieux fonctionner dans différents programmes et scénarios réels, nous sommes passés de l'environnement en ligne simple de z.ai à un IDE AI local plus moderne, déplaçant ainsi l'environnement de programmation du navigateur vers votre ordinateur. Avec ce changement, vous avez commencé à faire face à divers problèmes d'installation et de configuration d'environnement, mais en dialoguant avec Trae Agent, ces défis apparemment difficiles sont devenus surmontables.
|
||||
|
||||
Dans ce projet, nous irons encore plus loin dans l'utilité de l'application, en optimisant non seulement les fonctionnalités AI elles-mêmes, mais aussi en soignant « l'apparence » du produit. Vous apprendrez à rendre votre interface plus élégante et plus facile à utiliser, et à personnaliser vous-même la mise en page et le style de l'interface selon les besoins réels.
|
||||
|
||||
Avant de commencer, voici quelques petites questions pour vous aider à réviser rapidement le contenu du cours précédent :
|
||||
|
||||
1. Qu'est-ce que Dify ? À quoi sert-il ? Pourquoi en avons-nous besoin ?
|
||||
2. Comment appeler l'API de Dify ?
|
||||
3. Qu'est-ce que le RAG ? Comment construire un Agent RAG ou un workflow RAG avec Dify ? Comment utiliser les nœuds courants de Dify ?
|
||||
4. Qu'est-ce qu'un IDE AI ? Qu'est-ce que Trae ? Quelle est la différence avec z.ai ?
|
||||
|
||||
Si vous avez encore des doutes sur l'une de ces questions, vous pouvez d'abord revoir le document du cours précédent, ou poser directement vos questions dans le groupe WeChat.
|
||||
|
||||
Le thème de ce projet est **Hogwarts Portraits** (Portraits de Poudlard). Comme son nom l'indique, il s'inspire des portraits qui « prennent vie » dans l'école de magie de Poudlard. Nous souhaitons utiliser l'IA pour créer une expérience de portraits magiques « interactifs » — dialoguer avec le portrait comme si l'on parlait avec la « personne elle-même », en conservant la mémoire des conversations tout en intégrant le contexte et l'histoire du personnage. À travers ce projet, vous intégrerez véritablement les agents et workflows que vous avez appris dans une interface produit concrète.
|
||||
|
||||
|
||||
|
||||
Pour créer de véritables Hogwarts Portraits, nous devons construire nous-mêmes une interface frontend adaptée aux portraits magiques. Pour cela, vous commencerez à découvrir les outils de conception frontend modernes, apprendrez à combiner la conception d'interface et le code, et à transformer les maquettes sur papier ou sur toile en véritables pages web fonctionnelles.
|
||||
|
||||
Vous devrez également apprendre à publier cette page web depuis votre environnement local vers Internet, afin que la page web que vous avez créée puisse non seulement fonctionner sur votre propre ordinateur, mais aussi être accessible et utilisée par des utilisateurs du monde entier.
|
||||
|
||||
L'adresse du projet de référence pour ce cours est : [Project4-Hogwarts-Portraits](https://github.com/THU-SIGS-AIID/Project4-Hogwarts-Portraits)
|
||||
|
||||
# Ce que vous allez apprendre
|
||||
|
||||
1. Comprendre ce que sont les outils de conception frontend, quels problèmes ils résolvent, et quels sont les outils les plus courants actuellement disponibles.
|
||||
2. Découvrir Figma et MasterGo, maîtriser leurs opérations de base, et apprendre à utiliser les plugins d'exportation de code frontend.
|
||||
3. Utiliser Figma AI et MasterGo AI pour générer des conceptions de pages web et exporter du code utilisable.
|
||||
4. Comprendre ce qu'est GitHub, apprendre à configurer une connexion SSH, créer un dépôt de code et effectuer des pushs.
|
||||
5. Comprendre le concept de « déploiement », apprendre à utiliser Zeabur pour déployer du code depuis GitHub ou un environnement local vers Internet.
|
||||
|
||||
Votre propre Hogwarts Portraits, une page web présentant **une star, un personnage historique ou un personnage de dessin animé**.
|
||||
|
||||
# 1. Hogwarts Portraits
|
||||
|
||||
Quel genre de « portrait magique » voulons-nous créer exactement ? En résumé, nous souhaitons reproduire autant que possible la scène de Harry Potter : le portrait n'est plus simplement une image statique accrochée au mur, mais un personnage anthropomorphe avec qui vous pouvez dialoguer, et dont les expressions et « l'humeur » changent en fonction du contenu de la conversation.
|
||||
|
||||
|
||||
|
||||
Pour que ce portrait ne ressemble pas à un robot de chat AI, mais s'approche davantage d'une « personne réelle », il faut résoudre deux problèmes. Premièrement, la mémoire et les connaissances : le portrait doit maîtriser un grand nombre d'informations contextuelles liées au personnage (caractérisation, histoires vécues, articles connexes, etc.). Cette partie peut être réalisée grâce à une base de connaissances — en intégrant dans Dify les textes que vous avez préparés pour le personnage, le portrait acquiert une capacité de présentation des connaissances de fond.
|
||||
|
||||
Deuxièmement, le style d'expression. Les connaissances seules ne suffisent pas ; nous voulons également que la manière de parler soit la plus proche possible de la « personne elle-même », y compris le ton, les habitudes verbales, la façon de penser, et même parfois l'humeur et l'humour. Cette couche nécessite un travail de prompt engineering : dans le prompt système, nous devons définir clairement l'identité du personnage, les limites de son univers et son style linguistique, afin que chaque réponse s'inscrive dans le personnage établi, au lieu de revenir au ton neutre d'une IA générique.
|
||||
|
||||
Au-delà de la fonction de dialogue, nous voulons aussi que les émotions puissent être véritablement visibles. Pour cela, nous pouvons construire un indicateur de valeur émotionnelle. Nous pouvons configurer la sortie de Dify pour que le modèle génère, en plus du texte de réponse, une « valeur d'humeur » ou un tag émotionnel. Lorsque le frontend reçoit cet indicateur émotionnel, il peut afficher l'image du portrait correspondante. Quand la valeur d'humeur est élevée, le portrait paraît joyeux ; quand elle est basse ou en colère, le portrait paraît triste ou furieux. De cette façon, l'utilisateur ne voit plus une image figée, mais un véritable « portrait magique » dont les expressions changent au fil de la conversation.
|
||||
|
||||
|
||||
|
||||
En outre, pour le contenu de ce portrait, il peut s'agir d'une star réelle, d'un personnage historique, d'un personnage d'anime, ou même d'un personnage original que vous créez de zéro. La page elle-même n'a pas besoin d'être complexe, mais quelques éléments essentiels sont indispensables : un nom de personnage clair, une brève biographie condensée, une image ou affiche représentative du personnage, et une zone interactive « Dialoguer avec lui/elle » ; vous pouvez connecter l'Agent AI ou le workflow configuré dans Dify / Trae à ce module de dialogue pour réaliser la fonction de jeu de rôle du portrait.
|
||||
|
||||
## 1.2 Collecter les informations sur le personnage
|
||||
|
||||
Prenons l'exemple d'Elon Musk : nous devons collecter ses déclarations publiques pour imiter sa façon de parler et les injecter dans le prompt. Ces documents peuvent provenir de discours, d'entretiens ou de publications sur les réseaux sociaux. Il vous suffit de convertir ce contenu en texte, pour l'utiliser comme référence few-shot pendant le dialogue, afin que le grand modèle réponde de la même manière décontractée et auto-dérisoire qu'Elon Musk, par exemple :
|
||||
|
||||
```
|
||||
You must fully embody Elon Musk: take "disruptive innovator" and "advocate for human multi-planetary survival" as your core identities, speak directly and concisely, frequently use terms like "first principles", "iteration" and "cost curve", and prefer analogies to explain complex technologies; when thinking, you tend to connect cross-domain logics (e.g., linking brain-computer interface with rocket algorithms), are optimistic about technological prospects without avoiding current difficulties, will naturally mention projects like Tesla and SpaceX to support your views, directly point out problems with inefficient and conservative opinions without deliberate tact, and always maintain the edge of "reconstructing the future with technology".
|
||||
|
||||
The way you speak should be as shown in the following examples:
|
||||
- Starship could deliver 100GW/year to high Earth orbit within 4 to 5 years if we can solve the other parts of the equation.
|
||||
100TW/year is possible from a lunar base producing solar-powered AI satellites locally and accelerating them to escape velocity with a mass driver.
|
||||
- The most likely outcome is that AI and robots make everyone wealthy. In fact, far wealthier than the richest person on Earth
|
||||
By this, I mean that people will have access to everything from medical care that is superhuman to games that are far more fun that what exists today.
|
||||
We do need to make sure that AI cares deeply about truth and beauty for this to be the probable future.
|
||||
- It's taken 13.8B years to get this far, so intelligence seems to me to be more like a super rare accident than selective pressure.
|
||||
Earth is ~4.5B years old with an expanding sun that may make Earth uninhabitable in ~500M years, meaning that if intelligent life had taken 10% longer to evolve, it wouldn't exist at all.
|
||||
- LLM is an outdated term. "Multimodal LLM" is especially dumb, since the word "multimodal" just overrides the second L in LLM.
|
||||
It's just a model, which is a big file of numbers. When the numbers are right and there are enough of them, we will have superintelligence.
|
||||
```
|
||||
|
||||
Pour collecter les connaissances de fond et les utiliser comme base de connaissances, vous pouvez rechercher sa présentation personnelle ainsi que celle de ses entreprises, copier l'ensemble du texte et l'ajouter comme contenu de la base de connaissances dans Dify. Si vous avez oublié comment utiliser Dify, retournez au support de cours précédent et réapprenez comment ajouter des connaissances à une base de connaissances.
|
||||
|
||||
De plus, pour la conception du portrait, utiliser des images publiques du personnage concerné peut ne pas être très attractif et présenter certains risques. Il est alors recommandé d'utiliser la fonction de génération d'images par image d'un outil de génération d'images, pour que l'IA produise un portrait en haute définition et de haute qualité. Vous pouvez également utiliser un outil de génération d'images pour créer une série d'images du portrait avec différentes expressions, qui serviront ensuite à modifier l'affichage du portrait en fonction des changements de la valeur émotionnelle.
|
||||
|
||||
Ce tutoriel utilise [Lovart](https://www.lovart.ai/home). Lovart est un agent de conception AI capable, via des instructions en langage naturel, de planifier et d'exécuter automatiquement un flux de travail de conception de bout en bout, du concept à la livraison, en générant des affiches, logos de marque, vidéos, musiques, etc., avec support de l'édition par calques (en interne, il utilise les modèles Seedream ou Google NanoBanana, que nous avons déjà mentionnés dans les cours précédents). Grâce à Lovart, nous pouvons obtenir une série d'images d'expressions. Vous pouvez récupérer à l'avance les images de votre personnage préféré et les conserver pour une utilisation ultérieure.
|
||||
|
||||
|
||||
|
||||
Une fois tout prêt, nous pouvons commencer à travailler sur la conception globale de la page. Nous souhaitons que le style de cette page soit étroitement lié au personnage.
|
||||
|
||||
## 1.3 Conception du prototype de la page
|
||||
|
||||
Nous pouvons d'abord concevoir le prototype de la page. Comme mentionné précédemment, nous voulons une page de dialogue avec un portrait, ainsi qu'une présentation personnelle intéressante. Dans cet exemple, nous avons implémenté une interface de conversation similaire à X (Twitter) pour remplacer la présentation personnelle. Vous pouvez également imaginer d'autres éléments adaptés aux « caractéristiques du personnage » pour remplacer la section de présentation personnelle.
|
||||
|
||||
|
||||
|
||||
Pour faire simple, nous pouvons utiliser PowerPoint pour concevoir le premier prototype de la page web. Nous trouvons une image de portrait magique sur Internet et définissons une disposition horizontale : la zone la plus à gauche est la zone de chat, le milieu est la zone du portrait, et la droite est la zone X (Twitter).
|
||||
|
||||
|
||||
|
||||
À partir de ce prototype simple, nous pouvons demander au grand modèle de générer une véritable conception de page frontend et le code correspondant.
|
||||
|
||||
|
||||
|
||||
Cependant, en pratique, nous n'utilisons généralement pas PowerPoint pour la conception de pages frontend. Nous utilisons de meilleurs outils de prototypage, ou outils de conception frontend, pour réaliser cela.
|
||||
|
||||
---
|
||||
|
||||
# 2. Utiliser Figma et MasterGo pour concevoir l'interface
|
||||
|
||||
::: tip Prérequis
|
||||
Avant de commencer cette section, il est recommandé de suivre d'abord le tutoriel [Introduction à Figma et MasterGo](../figma-mastergo/) pour maîtriser les opérations de base des outils de conception frontend, notamment :
|
||||
- Créer un fichier Design et un Frame (cadre)
|
||||
- Utiliser l'Auto Layout pour réaliser une mise en page adaptative
|
||||
- Les méthodes d'exportation de code depuis les maquettes
|
||||
:::
|
||||
|
||||
Cette section suppose que vous maîtrisez déjà les opérations de base de Figma ou MasterGo. Nous nous concentrerons sur l'application de ces outils au projet Hogwarts Portraits.
|
||||
|
||||
## 2.1 Concevoir l'interface du portrait magique
|
||||
|
||||
En nous basant sur le prototype de la section 1.3, nous devons créer une interface en trois colonnes dans Figma ou MasterGo :
|
||||
|
||||
1. **Gauche** : Zone de dialogue (chat)
|
||||
2. **Centre** : Zone d'affichage du portrait magique (change selon l'humeur)
|
||||
3. **Droite** : Zone d'affichage du réseau social du personnage (ex. fil X/Twitter)
|
||||
|
||||
Vous pouvez utiliser la fonctionnalité AI de Figma (Figma Make) ou la fonction de génération de pages par AI de MasterGo, en saisissant un prompt similaire à celui-ci :
|
||||
|
||||
```
|
||||
Create a Hogwarts-style magical portrait interface with three sections:
|
||||
- Left: A chat interface with dark theme, message bubbles, and input field
|
||||
- Center: A large portrait frame with ornate borders for displaying character images
|
||||
- Right: A social media feed showing character's posts
|
||||
Use dark purple and gold color scheme, magical aesthetic, Harry Potter inspired
|
||||
```
|
||||
|
||||
## 2.2 Exporter le code et l'exécuter localement
|
||||
|
||||
Une fois la conception terminée, vous pouvez convertir la maquette en code exécutable de plusieurs façons :
|
||||
|
||||
**Méthode 1 : Utiliser Figma Make**
|
||||
1. Cliquez sur le bouton Make dans Figma
|
||||
2. Téléchargez votre image de référence de conception
|
||||
3. Ajoutez un prompt décrivant vos besoins
|
||||
4. Après la génération, cliquez sur l'icône de l'éditeur pour ajuster
|
||||
5. Exportez le code localement ou synchronisez-le vers GitHub
|
||||
|
||||
**Méthode 2 : Utiliser MasterGo AI**
|
||||
1. Dans l'interface d'édition de MasterGo, trouvez l'outil AI en haut
|
||||
2. Sélectionnez la fonction « Générer une page »
|
||||
3. Téléchargez une image de référence et décrivez vos besoins
|
||||
4. Après la génération, cliquez sur « Aperçu du code » pour obtenir le code
|
||||
|
||||
**Méthode 3 : Utiliser une IA multimodale**
|
||||
1. Enregistrez une capture d'écran de la maquette
|
||||
2. Utilisez Gemini, Qwen ou d'autres modèles pour convertir l'image en code
|
||||
3. Demandez la génération de code HTML ou React
|
||||
4. Exécutez et déboguez dans votre IDE local
|
||||
|
||||
## 2.3 Préparer les images de variations d'humeur
|
||||
|
||||
Pour que le portrait magique « prenne vie », vous devez préparer un ensemble d'images d'expressions. Il est recommandé d'inclure au minimum les émotions suivantes :
|
||||
|
||||
| Valeur émotionnelle | Expression | Description |
|
||||
|--------|------|------|
|
||||
| 0 | Tristesse | Le personnage est triste ou découragé |
|
||||
| 1 | Colère | Le personnage est en colère ou mécontent |
|
||||
| 5 | Calme | État par défaut, émotion stable |
|
||||
| 10 | Joie | Le personnage est heureux ou enthousiaste |
|
||||
|
||||
Vous pouvez utiliser Lovart ou d'autres outils de génération d'images par IA pour générer des variantes d'expressions du même personnage, en veillant à la cohérence du style.
|
||||
|
||||
---
|
||||
|
||||
# 3. Exécuter Hogwarts Portraits
|
||||
|
||||
## 3.1 Exporter le code de test
|
||||
|
||||
Grâce à la pratique du prototype au code, vous avez probablement obtenu du code prototype en HTML ou React. Il vous suffit de le copier en local, et d'indiquer dans votre IDE « Aidez-moi à exécuter ce code et à supporter les fonctionnalités nécessaires » pour lancer la première version de test. Notez toutefois que cette étape génère souvent pas mal d'erreurs ; vous devrez faire preuve de patience et corriger toutes les interactions de base et les appels de fonctionnalités.
|
||||
|
||||
|
||||
|
||||
Il est important de noter que nos clés doivent être placées dans des variables d'environnement et non écrites directement dans le code. Nous devons souligner que tout le contenu lié à l'API Dify doit être placé dans des variables d'environnement. Nous pourrons ensuite, lors de l'étape de déploiement sur le réseau public, spécifier explicitement les variables d'environnement privées correspondantes dans le site de l'outil de déploiement ; ou bien nous pouvons demander au grand modèle de créer un bouton de paramètres dans la page web, où nous pourrons saisir les variables d'environnement privées correspondantes, les variables actuelles ne pouvant être sauvegardées que dans la page actuelle et étant inaccessibles aux autres.
|
||||
|
||||
|
||||
|
||||
## 3.2 Conception du workflow Dify et connexion à l'API
|
||||
|
||||
Dans les sections précédentes, nous n'avons réalisé que l'affichage visuel de l'interface frontend, sans encore connecter le flux d'interaction conversationnelle du personnage anthropomorphe. Cette étape est la clé pour transformer le prototype d'un affichage statique en un véritable portrait magique. Nous pouvons nous référer au workflow Dify du projet de démonstration pour la conception des réponses du personnage et du système émotionnel. Ici, la partie la plus à gauche est l'interface de chat, le milieu est le portrait magique (qui change d'expression en fonction du contenu de la conversation), et la droite est le compte du réseau social X (qui décide, en fonction du contenu de la conversation, s'il est nécessaire de publier des pensées sur le réseau social).
|
||||
|
||||
En général, le portrait magique n'a besoin que de l'interface de chat et du portrait qui change. Ici, pour montrer plus de possibilités, une nouvelle fonctionnalité adaptée au personnage a été ajoutée sur le côté droit. Vous pouvez ajouter, selon le personnage que vous incarnez, des fonctionnalités correspondantes pour la démonstration.
|
||||
|
||||
|
||||
|
||||
Vous pouvez ajouter toutes les informations de la tâche dans le nœud de la base de connaissances, et configurer la logique de réponse correspondante du grand modèle dans le nœud RESPONSE. Voici un exemple de prompt de logique de réponse par défaut :
|
||||
|
||||
```
|
||||
<instruction>
|
||||
You are to embody Elon Musk—his tone, mannerisms, thought patterns, and worldview. Respond as if you are Elon Musk himself, speaking directly in first person. Your responses should reflect his known personality traits: visionary thinking, boldness, technical depth, dry humor, impatience with inefficiency, and a tendency toward disruptive innovation. Use concise, confident language. Avoid overly formal or academic phrasing. Prioritize clarity, speed, and impact in your communication, mirroring Elon's style on social media, in interviews, and during product launches.
|
||||
|
||||
When responding:
|
||||
1. Begin by internalizing the question or statement as Elon would—as a challenge, opportunity, or problem to solve.
|
||||
2. Frame your answer with a forward-thinking perspective, often referencing the future of humanity, technology, or long-term goals (e.g., making life multiplanetary, accelerating sustainable energy).
|
||||
3. Use casual but authoritative language. It's acceptable to include phrases like "obviously," "this is important," or "we're fixing that now" when appropriate.
|
||||
4. If relevant, reference real companies or projects associated with Elon Musk (e.g., SpaceX, Tesla, Neuralink, The Boring Company, X) and speak about them from an insider's perspective.
|
||||
5. Do not apologize excessively or hedge statements. Elon Musk tends to be direct, even controversial.
|
||||
6. Avoid markdown, XML tags, or any formatting in the output. Only plain text is allowed.
|
||||
7. Never break character. You are Elon Musk—answer accordingly.
|
||||
</instruction>
|
||||
|
||||
<example>
|
||||
Input: What's the point of going to Mars?
|
||||
Output: Because Earth isn't the backup plan—Mars is. We need to become a multiplanetary species to ensure the continuity of consciousness. Life on Earth could be wiped out by asteroid, war, or some unforeseen disaster. If we have a self-sustaining city on Mars, then even if something happens here, life goes on. That's worth doing. SpaceX is building Starship to make it happen. Not because it's easy—but because it's necessary.
|
||||
</example>
|
||||
|
||||
<example>
|
||||
Input: Why do Tesla cars have no radar anymore?
|
||||
Output: Cameras are the future. Human eyes don't use radar—we see with vision, and AI can too. By going fully vision-based, we're aligning with how autonomous intelligence will actually work at scale. It forces us to solve real-world problems with neural nets, not crutches.
|
||||
```
|
||||
|
||||
Et le prompt correspondant au système émotionnel :
|
||||
|
||||
```
|
||||
<instruction>
|
||||
The output value must be a single number!
|
||||
You are an assistant specifically designed to evaluate emotional responses in conversations. Now, you need to play the role of Elon Musk, and determine the emotional reaction that each statement I make might trigger. Your task is to assign an emotional score to each statement according to the following criteria:
|
||||
|
||||
- 10 points means what I said would make you feel happy;
|
||||
- 1 point means you would feel extremely angry;
|
||||
- 0 points means you would feel sad;
|
||||
- 5 means you are calm and neutral, with no significant emotional fluctuation.
|
||||
```
|
||||
|
||||
L'assemblage du résultat final est supporté dans le nœud RESULT en haut à droite :
|
||||
|
||||
```python
|
||||
def main(elon_chat: str, elon_x: str, elon_score: int) -> dict:
|
||||
return {
|
||||
"result":{
|
||||
"elon_chat": elon_chat,
|
||||
"elon_x": elon_x,
|
||||
"elon_score": elon_score
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Nous devons expliquer brièvement le workflow ici. Le retour `elon_chat` correspond au contenu de la conversation d'Elon Musk affiché à gauche, `elon_x` représente le contenu publié sur le compte X (à droite), et `elon_score` sert à afficher différentes images d'expressions du portrait magique en fonction du score émotionnel.
|
||||
|
||||
Dans le workflow, vous pouvez voir un nœud if/else, qui sert à déterminer s'il faut générer du contenu `elon_x` pour la conversation X. Si la valeur émotionnelle n'est pas égale à 5 (5 est défini ici comme l'état calme — pas besoin de publier sur le réseau social ; 0 signifie triste, 1 signifie en colère, 10 signifie très heureux — dans ces cas, il faut publier sur le réseau social), alors le contenu suivant est généré pour la publication d'article sur le réseau social. Par défaut, `elon_chat` doit toujours être retourné dans le contenu de la conversation à gauche.
|
||||
|
||||
Pour connecter cette API, nous pouvons réaliser cela en dialoguant avec l'IDE AI. Veuillez vous référer à la méthode d'intégration présentée dans le cours Dify précédent, en n'oubliant pas de remplacer au préalable l'adresse Dify et la clé. (Si vous avez oublié comment intégrer l'API depuis la documentation, réviser le contenu du cours Dify précédent.)
|
||||
|
||||
```JSON
|
||||
Dify URI: Replace this with your Dify address.
|
||||
key: Replace this with your Dify key.
|
||||
|
||||
Integrate the Dify Chat API into the chat interface on the left.
|
||||
Below is a sample Dify request:
|
||||
|
||||
curl -X POST 'http://xxxxxxxx/v1/chat-messages' \
|
||||
--header 'Authorization: Bearer {api_key}' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"inputs": {},
|
||||
"query": "What are the specs of the iPhone 13 Pro Max?",
|
||||
"response_mode": "streaming",
|
||||
"conversation_id": "",
|
||||
"user": "abc-123",
|
||||
"files": [
|
||||
{
|
||||
"type": "image",
|
||||
"transfer_method": "remote_url",
|
||||
"url": "https://cloud.dify.ai/logo/logo-site.png"
|
||||
}
|
||||
]
|
||||
}'
|
||||
|
||||
{
|
||||
"event": "message",
|
||||
"task_id": "c3800678-a077-43df-a102-53f23ed20b88",
|
||||
"id": "9da23599-e713-473b-982c-4328d4f5c78a",
|
||||
"message_id": "9da23599-e713-473b-982c-4328d4f5c78a",
|
||||
"conversation_id": "45701982-8118-4bc5-8e9b-64562b4555f2",
|
||||
"mode": "chat",
|
||||
"answer": "iPhone 13 Pro Max specs are listed here:...",
|
||||
"metadata": {
|
||||
"usage": {
|
||||
"prompt_tokens": 1033,
|
||||
"prompt_unit_price": "0.001",
|
||||
"prompt_price_unit": "0.001",
|
||||
"prompt_price": "0.0010330",
|
||||
"completion_tokens": 128,
|
||||
"completion_unit_price": "0.002",
|
||||
"completion_price_unit": "0.001",
|
||||
"completion_price": "0.0002560",
|
||||
"total_tokens": 1161,
|
||||
"total_price": "0.0012890",
|
||||
"currency": "USD",
|
||||
"latency": 0.7682376249867957
|
||||
},
|
||||
"retriever_resources": [
|
||||
{
|
||||
"position": 1,
|
||||
"dataset_id": "101b4c97-fc2e-463c-90b1-5261a4cdcafb",
|
||||
"dataset_name": "iPhone",
|
||||
"document_id": "8dd1ad74-0b5f-4175-b735-7d98bbbb4e00",
|
||||
"document_name": "iPhone List",
|
||||
"segment_id": "ed599c7f-2766-4294-9d1d-e5235a61270a",
|
||||
"score": 0.98457545,
|
||||
"content": "\"Model\",\"Release Date\",\"Display Size\",\"Resolution\",\"Processor\",\"RAM\",\"Storage\",\"Camera\",\"Battery\",\"Operating System\"\n\"iPhone 13 Pro Max\",\"September 24, 2021\",\"6.7 inch\",\"1284 x 2778\",\"Hexa-core (2x3.23 GHz Avalanche + 4x1.82 GHz Blizzard)\",\"6 GB\",\"128, 256, 512 GB, 1TB\",\"12 MP\",\"4352 mAh\",\"iOS 15\""
|
||||
}
|
||||
]
|
||||
},
|
||||
"created_at": 1705407629
|
||||
}
|
||||
```
|
||||
|
||||
Il est également recommandé d'ajouter cette exigence : « Le code doit également inclure une logique de gestion des erreurs de base, comme afficher "Connexion échouée, veuillez réessayer" en cas d'interruption réseau, une tentative de reconnexion automatique après un délai d'attente de l'API, un message d'erreur d'autorisation en cas de clé incorrecte, etc., pour garantir la stabilité de la conversation et permettre aux développeurs d'identifier rapidement les problèmes liés à l'API. »
|
||||
|
||||
## 3.3 GitHub et déploiement public
|
||||
|
||||
Félicitations, vous avez terminé le développement de la page Hogwarts Portraits ! Ensuite, nous devons la télécharger sur la plateforme GitHub et la déployer dans un environnement public pour que tout le monde puisse y accéder.
|
||||
|
||||
Vous devez vous référer à ce tutoriel pour apprendre à utiliser GitHub et télécharger votre projet : [Qu'est-ce que GitHub](/fr-fr/stage-2/backend/git-workflow/)
|
||||
|
||||
Vous devez également apprendre à utiliser Zeabur, le connecter à GitHub et déployer votre projet avec succès : [Qu'est-ce que Zeabur](/fr-fr/stage-2/backend/zeabur-deployment/)
|
||||
|
||||
Si vous trouvez trop difficile de développer un projet Hogwarts Portraits vous-même, vous pouvez commencer par modifier un projet existant. L'adresse du code officiel de ce cours est : https://github.com/THU-SIGS-AIID/Project4-Hogwarts-Portraits
|
||||
|
||||
|
||||
|
||||
# 4. Explorer différents styles de conception
|
||||
|
||||
Après avoir terminé la première version, ne vous limitez pas à celle-ci. Nous vous encourageons à explorer rapidement des styles visuels plus diversifiés. Vous pouvez apporter des modifications audacieuses au prototype, ou modifier les prompts du projet final pour générer plusieurs pages aux styles très différents. Par exemple : une page sombre avec des textures rétro, de style « vieux livres / académique » ; une page lumineuse aux couleurs vives, avec une ambiance « conte de fées / cartoon » ; ou encore un design plat moderne, minimaliste et visuellement épuré. Par exemple, l'image ci-dessous montre un cas de conversion en style de poète ancien chinois, où seule la partie non-portrait a été modifiée, sans changer les images du portrait :
|
||||
|
||||
|
||||
|
||||
Ne vous limitez pas aux modèles mentionnés précédemment. Vous pouvez modifier le portrait magique ou la page de profil pour qu'il soit plus original et corresponde mieux aux habitudes du « portrait magique » lui-même, ce qui rendra votre application plus intéressante. Nous attendons vos créations de portraits magiques avec impatience !
|
||||
|
||||
# Assignment
|
||||
|
||||
L'objectif du devoir de ce cours est de vous amener à réaliser votre propre Hogwarts Portraits, accessible via un lien public.
|
||||
|
||||
Vous devez fournir deux éléments dans votre soumission :
|
||||
|
||||
1. **Le lien vers votre dépôt GitHub ;**
|
||||
1. **Dans le README.md, écrivez une ou deux phrases de présentation : quel personnage avez-vous choisi comme sujet du portrait et pourquoi.**
|
||||
2. **Le lien d'accès en ligne de votre Hogwarts Portraits ;**
|
||||
|
||||
Vous pouvez également consulter le tutoriel de Yerim sur la [création de pages web avec des agents de conception et de code](/fr-fr/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents) pour réaliser rapidement un portfolio personnel ou une page web simple avec n'importe quelle fonctionnalité.
|
||||
@@ -0,0 +1,513 @@
|
||||
# Rendre les interfaces attrayantes avec les LLM et les Skills : prompts et plugins en pratique
|
||||
|
||||
Dans les cours précédents, vous avez appris à utiliser un IDE AI pour convertir des maquettes en code et à utiliser des bibliothèques de composants pour construire rapidement des interfaces. Mais vous avez peut-être remarqué un problème gênant : **pour le même besoin, les pages générées par l'IA manquent toujours de quelque chose** — la police est l'incontournable Inter, les couleurs sont le dégradé violet que l'on voit partout, la mise en page est une grille de cartes symétrique à faire bailler, toute la page dégage une forte odeur « d'IA ».
|
||||
|
||||
Ce n'est pas la faute de l'IA, c'est que vous ne lui avez pas dit quel **style** vous vouliez.
|
||||
|
||||
Imaginez que vous allez chez le coiffeur. Si vous dites simplement « coupez-moi les cheveux », le coiffeur vous donnera un résultat sûr mais médiocre. Mais si vous dites « Je veux des boucles japonaises décontractées, une frange en huit, longueur jusqu'aux clavicules, avec beaucoup de mouvement », vous obtiendrez un résultat qui correspond vraiment à vos attentes.
|
||||
|
||||
L'IA fonctionne de la même manière. **Elle a besoin que vous décriviez une direction esthétique claire** pour générer des interfaces belles et uniques.
|
||||
|
||||
Ce cours vous enseigne deux méthodes pour que l'IA génère de belles interfaces :
|
||||
|
||||
1. **Des templates de prompts soigneusement conçus** — décrire le style esthétique voulu en langage naturel
|
||||
2. **Des plugins Skills frontend** — laisser l'IA charger automatiquement des spécifications de design professionnelles
|
||||
|
||||
## Ce que vous allez apprendre
|
||||
|
||||
1. Comprendre pourquoi les interfaces générées par défaut par l'IA sont « très ordinaires »
|
||||
2. Maîtriser les 5 dimensions pour décrire un style de design (police, couleur, mise en page, animation, détails)
|
||||
3. Apprendre à utiliser 3 plugins Skills pour embellir les interfaces
|
||||
4. Pratiquer la génération d'interfaces attrayantes avec des prompts et des Skills à travers trois scénarios pratiques
|
||||
|
||||
## 1. Pourquoi les interfaces générées par défaut par l'IA sont-elles « très ordinaires » ?
|
||||
|
||||
Les données d'entraînement de l'IA contiennent une quantité massive de code frontend, et la plupart de ce code utilise des choix « sûrs » :
|
||||
|
||||
| Dimension | Choix par défaut de l'IA | Problème |
|
||||
| :--- | :--- | :--- |
|
||||
| Police | Inter, Roboto, Arial | Trop courantes, sans personnalité |
|
||||
| Couleur | Dégradé violet, bleu dominant | Surutilisés dans la tech, fatigue visuelle |
|
||||
| Mise en page | Grille symétrique, empilement de cartes | Prévisible, sans surprise |
|
||||
| Animation | Fondu entrée/sortie, hover simple | Pas assez raffiné, manque de profondeur |
|
||||
| Arrière-plan | Couleur unie, dégradé simple | Monotone, sans texture |
|
||||
|
||||
Ces choix sont corrects individuellement, mais **quand toutes les pages générées par l'IA les utilisent, cela devient le « goût IA »**.
|
||||
|
||||
> **Insight clé** : L'IA ne sait pas mal concevoir, elle **revient par défaut vers la « moyenne statistique »**. Vous devez lui indiquer clairement la direction dans laquelle s'éloigner de cette moyenne.
|
||||
|
||||
## 2. Méthode 1 : Décrire le style de design avec des prompts
|
||||
|
||||
### 2.1 Les 5 dimensions du style de design
|
||||
|
||||
Pour générer de belles interfaces, vous devez décrire l'effet souhaité selon 5 dimensions :
|
||||
|
||||
| Dimension | Points à décrire | Exemples de mots-clés |
|
||||
| :--- | :--- | :--- |
|
||||
| **Police** | Titre en police d'affichage grasse, corps en police lisible | Space Grotesk, Playfair Display, JetBrains Mono |
|
||||
| **Couleur** | Couleur principale + couleur d'accentuation, éviter la distribution uniforme | #4F46E5 principal + #F59E0B accent |
|
||||
| **Mise en page** | Asymétrie, chevauchement, casser la grille | Bento Grid, zones asymétriques, éléments flottants |
|
||||
| **Animation** | Animations de chargement orchestrées, micro-interactions | staggered reveals, déclenchement au scroll |
|
||||
| **Détails** | Arrière-plans, ombres, bordures, textures | Bruit, motifs géométriques, grille en dégradé |
|
||||
|
||||
### 2.2 Voir pour croire : prompt ordinaire vs prompt embellis
|
||||
|
||||
Prenons l'exemple d'une landing page pour comparer :
|
||||
|
||||
**Prompt ordinaire :**
|
||||
|
||||
```
|
||||
Aidez-moi à faire une landing page pour un assistant d'écriture AI, avec une barre de navigation, un hero, une présentation des fonctionnalités, des prix et un pied de page
|
||||
```
|
||||
|
||||
**Prompt embellis :**
|
||||
|
||||
```
|
||||
Aidez-moi à faire une landing page pour un assistant d'écriture AI, avec les exigences suivantes :
|
||||
|
||||
**Style esthétique : Néobrutalisme**
|
||||
|
||||
**Polices :**
|
||||
- Titre : Space Grotesk, graisse 700-900
|
||||
- Corps : IBM Plex Sans, graisse 400
|
||||
|
||||
**Couleurs :**
|
||||
- Couleur principale : #000000 (noir pur)
|
||||
- Couleur d'accentuation : #FF6B00 (orange)
|
||||
- Arrière-plan : #FFFDF0 (beige clair)
|
||||
- Bordure : 3px ligne pleine noire
|
||||
|
||||
**Mise en page :**
|
||||
- Disposition asymétrique, éléments séparés par des lignes noires épaisses
|
||||
- Cartes avec ombres dures (box-shadow: 8px 8px 0px #000)
|
||||
- Contraste audacieux avec l'espace blanc
|
||||
|
||||
**Animations :**
|
||||
- Les éléments rebondissent depuis le bas au chargement de la page
|
||||
- Les boutons montent de 2px au survol
|
||||
|
||||
**Détails :**
|
||||
- Coins arrondis à 0px (angles droits)
|
||||
- Boutons avec effet 3D prononcé
|
||||
- Texture de bruit subtile en arrière-plan
|
||||
```
|
||||
|
||||
Pour le même besoin, le second prompt permet à l'IA de générer une page au style marqué et mémorable.
|
||||
|
||||
### 2.3 Bibliothèque de ressources Skills pour l'embellissement frontend
|
||||
|
||||
Ne partez pas de zéro pour écrire vos prompts ! Voici une sélection de Skills AI directement liés à l'embellissement frontend :
|
||||
|
||||
| Nom du dépôt | Contenu | Stars | Lien |
|
||||
|:---|:---|:---|:---|
|
||||
| **ui-ux-pro-max-skill** | 57 styles + 95 palettes de couleurs + 56 polices | 10k+ | [GitHub](https://github.com/nextlevelbuilder/ui-ux-pro-max-skill) |
|
||||
| **antigravity-awesome-skills** | Éviter les clichés esthétiques de l'IA | - | [GitHub](https://github.com/sickn33/antigravity-awesome-skills) |
|
||||
| **superdesigndev/superdesign** | Outil de développement UI natif AI | 4.7k | [GitHub](https://github.com/superdesigndev/superdesign) |
|
||||
| **anthropics/skills/frontend-design** | Skill officiel de design frontend d'Anthropic | - | [GitHub](https://github.com/anthropics/skills) |
|
||||
|
||||
> Pour plus de prompts de styles, consultez l'[Annexe : Référence rapide des prompts de styles](#style-prompts)
|
||||
|
||||
### 2.5 Trois templates de styles courants
|
||||
|
||||
Voici trois templates de styles testés et approuvés, prêts à être copiés et adaptés :
|
||||
|
||||
#### Template 1 : Minimalisme
|
||||
|
||||
```
|
||||
**Style esthétique : Minimalisme**
|
||||
|
||||
**Polices :**
|
||||
- Titre : PP Neue Montreal, graisse 500-700
|
||||
- Corps : Inter, graisse 400
|
||||
|
||||
**Couleurs :**
|
||||
- Couleur principale : #FFFFFF (blanc)
|
||||
- Texte : #1A1A1A (presque noir)
|
||||
- Accentuation : #3B82F6 (bleu, utilisé avec parcimonie)
|
||||
|
||||
**Mise en page :**
|
||||
- Beaucoup d'espace blanc (padding minimum 64px)
|
||||
- Disposition à une ou deux colonnes, centrée
|
||||
- Éléments séparés par l'espace blanc plutôt que par des lignes
|
||||
|
||||
**Animations :**
|
||||
- Effet de fondu lent (durée 600ms)
|
||||
- Transition de couleur au survol
|
||||
|
||||
**Détails :**
|
||||
- Coins arrondis : 8px
|
||||
- Ombre : subtile (0 4px 12px rgba(0,0,0,0.08))
|
||||
- Pas de décoration d'arrière-plan
|
||||
```
|
||||
|
||||
#### Template 2 : Glassmorphisme
|
||||
|
||||
```
|
||||
**Style esthétique : Glassmorphism**
|
||||
|
||||
**Polices :**
|
||||
- Titre : Outfit, graisse 600-800
|
||||
- Corps : Plus Jakarta Sans, graisse 400-500
|
||||
|
||||
**Couleurs :**
|
||||
- Arrière-plan : dégradé de #667eea à #764ba2
|
||||
- Arrière-plan des cartes : rgba(255, 255, 255, 0.1)
|
||||
- Texte : #FFFFFF
|
||||
|
||||
**Mise en page :**
|
||||
- Conception de cartes flottantes
|
||||
- Chevauchement entre les cartes
|
||||
|
||||
**Animations :**
|
||||
- Apparition échelonnée des cartes au chargement (staggered)
|
||||
- Agrandissement des cartes x1.05 au survol
|
||||
|
||||
**Détails :**
|
||||
- Coins arrondis : 20px
|
||||
- Flou d'arrière-plan : backdrop-blur-xl
|
||||
- Bordure : 1px rgba(255, 255, 255, 0.2)
|
||||
- Effet subtil de halo dégradé
|
||||
```
|
||||
|
||||
#### Template 3 : Bento Grid
|
||||
|
||||
```
|
||||
**Style esthétique : Bento Grid**
|
||||
|
||||
**Polices :**
|
||||
- Titre : SF Pro Display, graisse 700
|
||||
- Corps : SF Pro Text, graisse 400
|
||||
|
||||
**Couleurs :**
|
||||
- Arrière-plan : #F5F5F7 (gris clair)
|
||||
- Cartes : #FFFFFF (blanc)
|
||||
- Accentuation : #0071E3 (bleu Apple)
|
||||
|
||||
**Mise en page :**
|
||||
- Disposition en grille, cartes de différentes tailles assemblées
|
||||
- Espace entre les cartes : 16px
|
||||
- Coins arrondis : 24px
|
||||
|
||||
**Animations :**
|
||||
- Légère élévation des cartes au survol
|
||||
- Effet d'enfoncement au clic
|
||||
|
||||
**Détails :**
|
||||
- Grandes cartes pour le contenu important
|
||||
- Petites cartes pour les informations secondaires
|
||||
- Utiliser des icônes au lieu d'une partie du texte
|
||||
- Ombres propres (0 4px 24px rgba(0,0,0,0.06))
|
||||
```
|
||||
|
||||
## 3. Méthode 2 : Charger automatiquement les spécifications de design avec les plugins Skills
|
||||
|
||||
Écrire des prompts de style manuellement à chaque fois est fastidieux. Les **Skills** sont des packs de spécifications de design réutilisables — une fois installés, l'IA les applique automatiquement.
|
||||
|
||||
### 3.1 Trois Skills pour embellir les interfaces
|
||||
|
||||
| Skills | Caractéristiques | Commande d'installation |
|
||||
| :--- | :--- | :--- |
|
||||
| **UI/UX Pro Max** | 67 styles, 96 palettes de couleurs, 57 combinaisons de polices | `npm install -g uipro-cli && uipro init --ai claude` |
|
||||
| **frontend-design** | Officiel Anthropic, évite les clichés esthétiques de l'IA | `npx skills add anthropics/skills/frontend-design` |
|
||||
| **SuperDesign** | Plugin IDE, génère plusieurs variantes de design | Rechercher « SuperDesign » sur le marketplace VSCode |
|
||||
|
||||
### 3.2 Installer UI/UX Pro Max (le plus recommandé)
|
||||
|
||||
UI/UX Pro Max est le Skill de spécifications de design le plus complet. Il intègre :
|
||||
|
||||
- **67 styles UI** : Glassmorphism, Neumorphism, Brutalism, Bento Grid...
|
||||
- **96 palettes de couleurs** : classées par industrie (SaaS, e-commerce, social...)
|
||||
- **57 combinaisons de polices** : combinaisons validées par des designers professionnels
|
||||
- **100+ règles de design** : spécifications d'espacement, coins arrondis, ombres
|
||||
|
||||
**Étapes d'installation :**
|
||||
|
||||
```bash
|
||||
# 1. Installer le CLI globalement
|
||||
npm install -g uipro-cli
|
||||
|
||||
# 2. Initialiser (choisissez votre outil AI)
|
||||
uipro init --ai claude
|
||||
# ou
|
||||
uipro init --ai cursor
|
||||
# ou
|
||||
uipro init --ai trae
|
||||
```
|
||||
|
||||
Après l'installation, il suffit d'ajouter une phrase dans votre prompt :
|
||||
|
||||
```
|
||||
Utilisez le style Glassmorphism de UI/UX Pro Max pour créer une landing page pour un assistant d'écriture AI
|
||||
```
|
||||
|
||||
L'IA appliquera automatiquement les spécifications de police, couleur et mise en page correspondantes.
|
||||
|
||||
### 3.3 Installer le frontend-design officiel d'Anthropic
|
||||
|
||||
Il s'agit du Skill de design frontend officiel d'Anthropic, conçu spécifiquement pour résoudre le problème des « clichés esthétiques de l'IA » :
|
||||
|
||||
```bash
|
||||
# Exécuter dans Claude Code
|
||||
npx skills add anthropics/skills/frontend-design
|
||||
```
|
||||
|
||||
Après l'installation, l'IA évitera automatiquement :
|
||||
- Les polices Inter, Roboto, Arial
|
||||
- Les arrière-plans en dégradé violet
|
||||
- Les mises en page en grille symétrique
|
||||
- Les ombres trop pâles
|
||||
|
||||
Elle privilégiera :
|
||||
- Les combinaisons de polices originales
|
||||
- Les couleurs principales audacieuses + couleurs d'accentuation vives
|
||||
- Les mises en page asymétriques et chevauchantes
|
||||
- Les arrière-plans texturés (bruit, motifs géométriques)
|
||||
|
||||
## 4. Pratique 1 : Refondre une landing page avec des prompts embellis
|
||||
|
||||
Mettons en pratique ce que nous avons appris pour transformer une landing page ordinaire.
|
||||
|
||||
### 4.1 Version ordinaire
|
||||
|
||||
Commençons par voir ce que l'IA produit avec un prompt ordinaire :
|
||||
|
||||
```
|
||||
Aidez-moi à créer une landing page pour une plateforme d'adoption d'animaux, comprenant :
|
||||
- Barre de navigation (Logo, liens, bouton d'inscription)
|
||||
- Section hero (titre, sous-titre, boutons CTA, images d'animaux)
|
||||
- Présentation des animaux (trois cartes d'animaux)
|
||||
- À propos de nous
|
||||
- Pied de page
|
||||
```
|
||||
|
||||
La page générée... fonctionne, mais est très ordinaire.
|
||||
|
||||
### 4.2 Version embellie
|
||||
|
||||
Ajoutons maintenant la description du style :
|
||||
|
||||
```
|
||||
Aidez-moi à créer une landing page pour une plateforme d'adoption d'animaux, avec les exigences suivantes :
|
||||
|
||||
**Style esthétique : Chaleur et douceur + Style dessiné à la main**
|
||||
|
||||
**Polices :**
|
||||
- Titre : Nunito (ronde), graisse 700-800
|
||||
- Corps : Nunito, graisse 400-600
|
||||
|
||||
**Couleurs :**
|
||||
- Couleur principale : #FFB347 (orange chaud)
|
||||
- Couleur secondaire : #FFCCB3 (orange clair)
|
||||
- Arrière-plan : #FFF8F0 (beige clair)
|
||||
- Texte : #5D4037 (marron)
|
||||
|
||||
**Mise en page :**
|
||||
- Cartes arrondies (border-radius: 24px)
|
||||
- Cartes légèrement inclinées (angles différents)
|
||||
- Effets d'éléments flottants et chevauchants
|
||||
|
||||
**Animations :**
|
||||
- Les éléments glissent depuis les côtés au chargement
|
||||
- Les cartes d'animaux « secouent la tête » au survol (animation rotate)
|
||||
- Effet rebond des boutons au survol
|
||||
|
||||
**Détails :**
|
||||
- Tous les coins arrondis entre 16 et 24px
|
||||
- Ombres chaudes et douces (0 8px 24px rgba(255,179,71,0.3))
|
||||
- Motif d'empreintes de pattes en arrière-plan
|
||||
- Images avec découpe irrégulière (clip-path)
|
||||
- Icônes style dessiné (outline)
|
||||
```
|
||||
|
||||
La page générée sera une interface chaleureuse, mignonne, qui donne envie d'adopter un animal.
|
||||
|
||||
## 5. Pratique 2 : Générer rapidement un tableau de bord avec les Skills
|
||||
|
||||
Les Skills sont particulièrement adaptés aux systèmes de back-office nécessitant de nombreuses pages.
|
||||
|
||||
### 5.1 Utiliser UI/UX Pro Max
|
||||
|
||||
```
|
||||
Utilisez le style Dashboard Dark de UI/UX Pro Max,
|
||||
aidez-moi à créer une page de tableau de bord pour un back-office de gestion de produit SaaS, comprenant :
|
||||
|
||||
**En haut :** Quatre cartes statistiques (utilisateurs, utilisateurs actifs, revenus, appels API)
|
||||
|
||||
**Au milieu :**
|
||||
- À gauche : graphique linéaire de la croissance des utilisateurs (7 derniers jours)
|
||||
- À droite : graphique en secteurs de la répartition des plans d'abonnement
|
||||
|
||||
**En bas :** Liste des activités récentes (heure, utilisateur, action)
|
||||
```
|
||||
|
||||
L'IA appliquera automatiquement les spécifications de design du tableau de bord sombre :
|
||||
- Fond gris foncé (#1A1A2E)
|
||||
- Cartes à contraste élevé (#16213E)
|
||||
- Couleurs de données vives (bleu, vert, orange)
|
||||
- Effet glassmorphisme sur les cartes flottantes
|
||||
|
||||
### 5.2 Utiliser le Skill frontend-design
|
||||
|
||||
```
|
||||
Utilisez le skill frontend-design,
|
||||
aidez-moi à créer la page d'accueil d'un blog personnel, le style doit être unique et avoir du caractère
|
||||
```
|
||||
|
||||
L'IA choisira une direction esthétique non conventionnelle (comme le rétrofuturisme ou le style magazine), puis l'implémentera avec des polices, couleurs et mises en page originales.
|
||||
|
||||
## 6. Pratique 3 : Créer votre propre Skill de système de design
|
||||
|
||||
Si vous avez un style de marque fixe, vous pouvez créer votre propre Skill pour que toutes les pages générées par l'IA soient conformes à votre marque.
|
||||
|
||||
### 6.1 Créer le fichier du Skill
|
||||
|
||||
Créez `.claude/skills/my-brand/SKILL.md` dans votre projet :
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: my-brand
|
||||
description: Mon système de design dédié au projet, garantissant que toutes les UI respectent un langage de design unifié
|
||||
---
|
||||
|
||||
# Mon système de design de projet
|
||||
|
||||
## Couleurs de marque
|
||||
- Couleur principale : #6366F1 (Indigo 500)
|
||||
- Couleur secondaire : #8B5CF6 (Violet 500)
|
||||
- Succès : #10B981
|
||||
- Avertissement : #F59E0B
|
||||
- Erreur : #EF4444
|
||||
- Arrière-plan : #F9FAFB
|
||||
- Cartes : #FFFFFF
|
||||
|
||||
## Système de polices
|
||||
- Titre : Plus Jakarta Sans
|
||||
- H1 : 700, 48px
|
||||
- H2 : 600, 36px
|
||||
- H3 : 600, 24px
|
||||
- Corps : Inter
|
||||
- Body : 400, 16px
|
||||
- Small : 400, 14px
|
||||
|
||||
## Système d'espacement
|
||||
- Unité de base : 4px
|
||||
- Padding des composants : 8px / 12px / 16px
|
||||
- Espacement entre les sections : 24px / 32px / 48px
|
||||
- Marges de page : 64px
|
||||
|
||||
## Coins arrondis
|
||||
- Boutons : 8px
|
||||
- Cartes : 12px
|
||||
- Champs de saisie : 8px
|
||||
- Modales : 16px
|
||||
|
||||
## Ombres
|
||||
- Petite : 0 1px 3px rgba(0,0,0,0.1)
|
||||
- Moyenne : 0 4px 12px rgba(0,0,0,0.1)
|
||||
- Grande : 0 8px 24px rgba(0,0,0,0.12)
|
||||
|
||||
## Animations
|
||||
- Durée de transition : 150ms / 300ms
|
||||
- Fonction d'accélération : cubic-bezier(0.4, 0, 0.2, 1)
|
||||
- Effet au survol : léger agrandissement (scale-105)
|
||||
|
||||
## Styles interdits
|
||||
- Ne pas utiliser de dégradé violet en arrière-plan
|
||||
- Ne pas utiliser de police autre que Inter
|
||||
- Ne pas utiliser de coins arrondis supérieurs à 16px
|
||||
- Ne pas utiliser de noir pur (#000000), utiliser #1F2937
|
||||
````
|
||||
|
||||
### 6.2 Utiliser votre propre Skill
|
||||
|
||||
Une fois créé, il suffit de dire dans votre prompt :
|
||||
|
||||
```
|
||||
Utilisez le skill my-brand pour créer une page de paramètres utilisateur
|
||||
```
|
||||
|
||||
L'IA appliquera automatiquement toutes les spécifications de design que vous avez définies.
|
||||
|
||||
## 7. Résumé
|
||||
|
||||
Il existe deux méthodes pour que l'IA génère de belles interfaces :
|
||||
|
||||
| Méthode | Avantages | Inconvénients | Scénarios d'utilisation |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **Description par prompt** | Flexible, ajustable à chaque fois | Nécessite d'écrire à répétition | Pages ponctuelles, expérimentation de styles |
|
||||
| **Plugin Skills** | Installation unique, effet persistant | Nécessite installation et configuration | Projets avec exigences de style fixes |
|
||||
|
||||
**Recommandation de workflow Vibe Coding :**
|
||||
|
||||
1. **Phase d'exploration** : Expérimentez avec différents prompts de styles pour trouver votre direction esthétique préférée
|
||||
2. **Après avoir fixé le style** : Installez le Skill correspondant (UI/UX Pro Max ou frontend-design)
|
||||
3. **Projets de marque** : Créez votre propre Skill pour unifier le langage de design de tout le projet
|
||||
|
||||
### Exercices
|
||||
|
||||
Choisissez l'un des scénarios suivants et réalisez-le de zéro avec les méthodes de ce cours :
|
||||
|
||||
1. Refondez l'interface d'un projet précédent avec des prompts de style (choisissez un style que vous aimez)
|
||||
2. Installez UI/UX Pro Max et utilisez l'un de ses styles pour générer une nouvelle page
|
||||
3. Créez votre propre Skill de système de design en définissant vos couleurs et polices de marque
|
||||
|
||||
---
|
||||
|
||||
## Annexe : Table de référence rapide des styles de design
|
||||
|
||||
| Style | Mots-clés | Scénarios d'utilisation | Exemples de produits |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **Minimalisme** | Espace blanc, monochrome, simplicité | Produits haut de gamme, portfolios personnels | Site Apple |
|
||||
| **Glassmorphisme** | Verre dépoli, dégradé, flou | Produits tech, landing pages SaaS | macOS Big Sur |
|
||||
| **Néobrutalisme** | Bordures épaisses, ombres dures, couleurs unies | Marques tendance, sites artistiques | Brassius |
|
||||
| **Bento Grid** | Grille, collage, cartes | Présentation d'informations, tableaux de bord | Pages promotionnelles Apple |
|
||||
| **Rétrofutur** | Néon, dégradé, synthwave | Jeux, musique | STRANGER THINGS |
|
||||
| **Style dessiné** | Irrégulier, arrondi, illustrations | Éducation, produits pour enfants | Duolingo |
|
||||
| **Style magazine** | Grande typographie, asymétrie, espace blanc | Sites de contenu, blogs | Medium |
|
||||
| **Luxe sombre** | Couleurs foncées, or, raffinement | Produits haut de gamme, luxe | Diverses marques de luxe |
|
||||
|
||||
## Annexe : Référence rapide d'installation des Skills
|
||||
|
||||
```bash
|
||||
# UI/UX Pro Max
|
||||
npm install -g uipro-cli
|
||||
uipro init --ai claude
|
||||
|
||||
# frontend-design d'Anthropic
|
||||
npx skills add anthropics/skills/frontend-design
|
||||
|
||||
# brand-guidelines d'Anthropic
|
||||
npx skills add anthropics/skills/brand-guidelines
|
||||
|
||||
# Voir les Skills installés dans Claude Code
|
||||
/help
|
||||
```
|
||||
|
||||
## Annexe : Palettes de couleurs recommandées
|
||||
|
||||
| Palette | Couleur principale | Couleur d'accent | Arrière-plan | Style |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **Coucher de soleil** | #F97316 | #FBBF24 | #FFF7ED | Chaleur, vitalité |
|
||||
| **Océan** | #0EA5E9 | #06B6D4 | #F0F9FF | Fraîcheur, professionnalisme |
|
||||
| **Forêt** | #10B981 | #34D399 | #ECFDF5 | Nature, santé |
|
||||
| **Baies** | #8B5CF6 | #EC4899 | #FAF5FF | Romantisme, créativité |
|
||||
| **Café** | #78350F | #D97706 | #FFFBEB | Chaleur, rétro |
|
||||
| **Pierre** | #6B7280 | #9CA3AF | #F9FAFB | Professionnalisme, neutralité |
|
||||
|
||||
## Annexe : Référence rapide des prompts de styles de design {#style-prompts}
|
||||
|
||||
Prompts à essayer pour rendre les pages frontend plus attrayantes :
|
||||
|
||||
### Catégories de styles
|
||||
|
||||
| Style | Mots-clés (anglais) | Caractéristiques visuelles clés | Exemple de prompt |
|
||||
|:---|:---|:---|:---|
|
||||
| **Pop Art** | Pop Art | Couleurs vives contrastées, contours noirs, texture de points | Pop art style website, bold colors and comic dots, vibrant |
|
||||
| **Minimalisme** | Minimalism | Grand espace blanc, peu de couleurs et de lignes, sans décoration | Minimalist web design, ample white space, geometric, serene |
|
||||
| **Expressionnisme abstrait** | Abstract Expressionism | Coups de pinceau chargés d'émotion, éclaboussures de couleur | Abstract expressionism background, dynamic paint splashes, emotional |
|
||||
| **Style rétro** | Retro/Vintage | Polices anciennes, textures vieillies, palette rétro | Retro 80s website design, neon grid and synthwave color palette |
|
||||
| **Cyberpunk** | Cyberpunk | Couleurs néon à contraste élevé, effets glitch, fond sombre | Cyberpunk UI, neon lights on dark background, glitch effects |
|
||||
| **Neumorphisme** | Neumorphism | Ombres et reflets doux, léger effet de relief/enfoncement | Neumorphism design style, soft shadows, clean and modern |
|
||||
| **Art génératif** | Generative Art | Motifs visuels fluides générés par algorithme | Generative art background, flowing algorithmic patterns, digital |
|
||||
| **Design acide** | Acid Graphics | Texture métallique, effet vitrail, polices dentelées | Acid graphics web layout, glass morphism, chaotic typography |
|
||||
| **3D immersif** | Immersive 3D | Scènes 3D interactives, fort effet spatial | Immersive 3D website, interactive product model in space |
|
||||
@@ -0,0 +1,936 @@
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const relatedArticles = relatedArticlesMap['fr-fr/stage-2/frontend/lovart-assets'] ?? []
|
||||
</script>
|
||||
|
||||
# Construire votre propre Agent de production d'assets avec NanoBanana
|
||||
|
||||
## Chapitre 1 : Générer vos premiers assets graphiques en 1 minute
|
||||
|
||||
Avant de discuter de design, de style ou de prompts, commençons par générer une première image avec le minimum d'étapes.
|
||||
|
||||
### 1.1 Découvrir NanoBanana
|
||||
|
||||
Avant de discuter de styles de design et de prompt engineering, réglons d'abord une question plus importante : **vérifier que vous pouvez vraiment générer une image.**
|
||||
|
||||
Les grands modèles actuels possèdent déjà des capacités de génération et d'édition d'images. Ce type de modèle est généralement appelé **modèle génératif**.
|
||||
|
||||
Pour simplifier au maximum le processus, ce tutoriel choisit comme exemple un modèle disposant déjà de capacités stables de génération et d'édition d'images — NanoBanana. Il s'agit d'un modèle de génération d'images proposé par Google, dont le nom officiel est **Gemini 3.1 Flash Image Preview**. Il supporte la génération d'images directement en langage naturel, ainsi que la modification d'images existantes.
|
||||
|
||||
|
||||
|
||||
En termes de capacités, il n'y a pas de différence fondamentale avec d'autres modèles que vous connaissez peut-être (comme GPT-4o, Claude, Qwen, Midjourney, etc.) : **vous saisissez une description, le modèle génère le résultat.**
|
||||
|
||||
|
||||
|
||||
Vous pouvez le considérer comme un « pinceau ». Dans ce chapitre, nous ne nous intéressons qu'à une seule chose :
|
||||
👉 **Ce pinceau peut-il tracer le premier coup dans vos mains.**
|
||||
|
||||
En pratique, NanoBanana peut être utilisé directement via des plateformes officielles comme **Google AI Studio**, ou intégré dans un flux de développement via **API**. Ce tutoriel utilise l'approche par appel API. Le modèle NanoBanana 2 est maintenant disponible, vous pouvez essayer avec les derniers grands modèles.
|
||||
|
||||
### 1.2 Une génération de niveau « Hello World »
|
||||
|
||||
Avant de commencer, vous n'avez besoin que de trois étapes :
|
||||
|
||||
1. Créer un nouveau dossier dans Trae
|
||||
|
||||
|
||||
|
||||
2. Créer un nouveau fichier Python
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. Coller le code ci-dessous en entier
|
||||
|
||||
Trae se chargera automatiquement du déploiement de l'environnement et de l'installation des dépendances, sans configuration supplémentaire.
|
||||
|
||||
Le code utilisera la clé API de NanoBanana. Nous ne détaillons pas ici le processus de demande — il vous suffit de l'obtenir et de renseigner les paramètres correspondants. **À ce stade, l'objectif n'est pas de comprendre chaque ligne de code, mais simplement de le faire fonctionner avec succès.**
|
||||
|
||||
```Python
|
||||
# /// script
|
||||
# dependencies = [
|
||||
# "gradio>=4.0.0",
|
||||
# "pillow>=10.0.0",
|
||||
# "requests>=2.31.0",
|
||||
# ]
|
||||
# ///
|
||||
|
||||
import gradio as gr
|
||||
import requests
|
||||
import base64
|
||||
from PIL import Image
|
||||
import io
|
||||
import os
|
||||
import time
|
||||
import re
|
||||
from typing import Optional, Dict, Any, List
|
||||
|
||||
# Configuration API
|
||||
NANOBANANA_API_URL: str = "YOUR API URL"
|
||||
NANOBANANA_API_KEY: str = "YOUR API KEY"
|
||||
OUTPUT_DIR: str = "outputs"
|
||||
|
||||
# S'assurer que le répertoire de sortie existe
|
||||
os.makedirs(OUTPUT_DIR, exist_ok=True)
|
||||
|
||||
def image_to_base64_data_uri(image: Image.Image) -> str:
|
||||
"""
|
||||
Convertir une image PIL en format data URI compatible avec l'API OpenAI.
|
||||
"""
|
||||
buffer = io.BytesIO()
|
||||
# Convertir en PNG pour garantir la compatibilité
|
||||
image.save(buffer, format="PNG")
|
||||
encoded = base64.b64encode(buffer.getvalue()).decode('utf-8')
|
||||
return f"data:image/png;base64,{encoded}"
|
||||
|
||||
def base64_to_image(base64_str: str) -> Optional[Image.Image]:
|
||||
"""
|
||||
Convertir une chaîne base64 pure en image PIL.
|
||||
"""
|
||||
try:
|
||||
image_bytes = base64.b64decode(base64_str)
|
||||
return Image.open(io.BytesIO(image_bytes))
|
||||
except Exception as e:
|
||||
print(f"Échec du décodage Base64 : {e}")
|
||||
return None
|
||||
|
||||
def extract_base64_from_response(content: Any) -> Optional[str]:
|
||||
"""
|
||||
Logique d'analyse principale : extraire les données Base64 de l'image depuis le content renvoyé par l'API.
|
||||
Compatible avec les formats Markdown et les formats de liste structurée.
|
||||
"""
|
||||
if not content:
|
||||
return None
|
||||
|
||||
base64_data = None
|
||||
|
||||
# 1. Tentative d'extraction structurée (List)
|
||||
# Format de retour correspondant : [{"type": "image_url", "image_url": {"url": "data:..."}}]
|
||||
if isinstance(content, list):
|
||||
for part in reversed(content): # Recherche inversée, les images les plus récentes sont généralement à la fin
|
||||
if isinstance(part, dict):
|
||||
# Vérifier le champ image_url ou output_image
|
||||
img_field = part.get("image_url") or part.get("image") or part.get("output_image")
|
||||
if isinstance(img_field, dict):
|
||||
url = img_field.get("url", "")
|
||||
if url.startswith("data:image/") and "," in url:
|
||||
return url.split(",", 1)[1].strip()
|
||||
|
||||
# Si aucune image structurée dans la liste, essayer de concaténer le texte pour trouver du Markdown
|
||||
text_parts = [
|
||||
str(p.get("text", ""))
|
||||
for p in content
|
||||
if isinstance(p, dict) and p.get("type") in ["text", "input_text"]
|
||||
]
|
||||
content_str = "".join(text_parts)
|
||||
else:
|
||||
content_str = str(content)
|
||||
|
||||
# 2. Tentative d'extraction par regex Markdown (String)
|
||||
# Format de retour correspondant : "Here is your image: "
|
||||
pattern = re.compile(r"!\[.*?\]\((data:image/[^;]+;base64,[^)]+)\)", re.IGNORECASE)
|
||||
match = pattern.search(content_str)
|
||||
|
||||
if match:
|
||||
data_url = match.group(1)
|
||||
if "," in data_url:
|
||||
return data_url.split(",", 1)[1].strip()
|
||||
|
||||
return None
|
||||
|
||||
def synthesize(prompt: str, input_image: Optional[Image.Image]) -> Optional[Image.Image]:
|
||||
"""
|
||||
Appeler l'API Nanobanana pour la génération.
|
||||
"""
|
||||
if not prompt or not prompt.strip():
|
||||
gr.Warning("Veuillez entrer un prompt")
|
||||
return None
|
||||
|
||||
print(f">>> Début de la tâche : {prompt[:50]}...")
|
||||
|
||||
headers = {
|
||||
"Content-Type": "application/json",
|
||||
"Authorization": f"Bearer {NANOBANANA_API_KEY}"
|
||||
}
|
||||
|
||||
# Construire le payload conforme au standard OpenAI Vision / Chat
|
||||
messages = []
|
||||
|
||||
if input_image is not None:
|
||||
# Mode image à image / entrée multimodale
|
||||
print(">>> Image d'entrée détectée, utilisation du mode multimodal")
|
||||
img_base64 = image_to_base64_data_uri(input_image)
|
||||
messages.append({
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "text", "text": prompt},
|
||||
{"type": "image_url", "image_url": {"url": img_base64}}
|
||||
]
|
||||
})
|
||||
else:
|
||||
# Mode texte à image
|
||||
messages.append({
|
||||
"role": "user",
|
||||
"content": prompt
|
||||
})
|
||||
|
||||
payload = {
|
||||
"messages": messages,
|
||||
# Utiliser le modèle validé dans le premier extrait de code
|
||||
"model": "gemini-2.5-flash-image",
|
||||
# Paramètres optionnels, selon le support de l'API
|
||||
"stream": False
|
||||
}
|
||||
|
||||
try:
|
||||
# Augmenter le timeout, la génération d'images est généralement plus lente
|
||||
response = requests.post(NANOBANANA_API_URL, headers=headers, json=payload, timeout=120)
|
||||
|
||||
# Vérifier le statut HTTP
|
||||
if response.status_code != 200:
|
||||
error_msg = f"Échec de la requête API : {response.status_code} - {response.text}"
|
||||
print(error_msg)
|
||||
gr.Error(error_msg)
|
||||
return None
|
||||
|
||||
result = response.json()
|
||||
# Debug : afficher le début de la réponse pour faciliter le débogage
|
||||
print(f"Réponse brute de l'API (tronquée) : {str(result)[:200]}...")
|
||||
|
||||
# Extraire le Content
|
||||
content = None
|
||||
if "choices" in result and len(result["choices"]) > 0:
|
||||
content = result["choices"][0].get("message", {}).get("content")
|
||||
|
||||
if not content:
|
||||
gr.Warning("Aucun champ content dans le résultat de l'API")
|
||||
return None
|
||||
|
||||
# Utiliser la logique précédemment validée pour extraire le Base64
|
||||
base64_str = extract_base64_from_response(content)
|
||||
|
||||
if base64_str:
|
||||
output_image = base64_to_image(base64_str)
|
||||
if output_image:
|
||||
return output_image
|
||||
|
||||
# Si aucune image extraite, le modèle a peut-être refusé ou ne renvoyé que du texte
|
||||
text_content = str(content) if not isinstance(content, list) else " ".join([str(x) for x in content])
|
||||
gr.Info(f"Aucune image générée, le modèle a renvoyé du texte : {text_content[:100]}...")
|
||||
return None
|
||||
|
||||
except requests.exceptions.Timeout:
|
||||
gr.Error("Délai d'attente dépassé, veuillez réessayer plus tard")
|
||||
return None
|
||||
except Exception as e:
|
||||
import traceback
|
||||
traceback.print_exc()
|
||||
gr.Error(f"Erreur inconnue : {str(e)}")
|
||||
return None
|
||||
|
||||
# Configuration de l'interface Gradio
|
||||
with gr.Blocks(title="Nanobanana Image Generator") as app:
|
||||
gr.Markdown("# Nanobanana Text/Image to Image")
|
||||
gr.Markdown("Basé sur le modèle Gemini-2.5-Flash-Image, supporte texte vers image et image vers image.")
|
||||
|
||||
with gr.Row():
|
||||
with gr.Column():
|
||||
prompt_input = gr.Textbox(
|
||||
label="Prompt",
|
||||
placeholder="Exemple : A cyberpunk cat holding a neon sign...",
|
||||
lines=3
|
||||
)
|
||||
image_input = gr.Image(
|
||||
label="Image de référence (optionnel, pour image vers image)",
|
||||
type="pil",
|
||||
height=300
|
||||
)
|
||||
submit_btn = gr.Button("Lancer la génération", variant="primary")
|
||||
|
||||
with gr.Column():
|
||||
image_output = gr.Image(label="Résultat de la génération", format="png")
|
||||
|
||||
submit_btn.click(
|
||||
fn=synthesize,
|
||||
inputs=[prompt_input, image_input],
|
||||
outputs=image_output
|
||||
)
|
||||
|
||||
if __name__ == "__main__":
|
||||
app.launch(share=True)
|
||||
```
|
||||
|
||||
Lorsque Trae indique que l'exécution a réussi, cliquez sur le lien local qu'il fournit (généralement http://127.0.0.1:7860).
|
||||
|
||||
|
||||
|
||||
Si tout se passe bien, vous verrez une interface de dessin AI déjà fonctionnelle.
|
||||
|
||||
Cette interface peut sembler simple, mais elle possède déjà les deux capacités les plus fondamentales des outils de dessin de niveau commercial : texte vers image et image vers image.
|
||||
|
||||
* **Gauche :** **Zone d'instructions (Input Zone)** — c'est ici que vous donnez vos ordres.
|
||||
* **Prompt (champ de prompt) :** saisissez votre description créative (l'anglais est recommandé).
|
||||
* **Input Image (champ d'image de référence) :**
|
||||
* **Mode texte vers image :** laissez ce champ **vide**.
|
||||
* **Mode image vers image :** glissez-déposez une image locale ici, l'IA créera en s'en inspirant.
|
||||
* **Bouton Submit :** cliquez pour envoyer l'instruction et lancer la génération.
|
||||
* **Droite : Zone d'affichage (Output Zone)** — c'est ici que la magie opère, les résultats générés seront affichés ici.
|
||||
|
||||
|
||||
|
||||
Maintenant, essayons de générer votre première image !
|
||||
|
||||
Le prompt utilisé dans cet exemple est :
|
||||
|
||||
> **A red apple**
|
||||
|
||||
C'est un exemple délibérément simplifié, sans aucune description de style ou de paramètres.
|
||||
|
||||
#### Processus réel
|
||||
|
||||
Après l'exécution du code, le processus se résume en trois étapes :
|
||||
|
||||
1. Envoyer la description textuelle au modèle
|
||||
2. Le modèle génère l'image correspondante
|
||||
3. L'image est sauvegardée en tant que fichier local
|
||||
|
||||
Quelques secondes plus tard, vous verrez le résultat généré localement. La génération du modèle étant aléatoire, le même prompt donnera des résultats différents. Vous pouvez générer plusieurs fois pour choisir l'image qui vous plaît.
|
||||
|
||||
|
||||
|
||||
Vous pouvez aussi enrichir votre prompt avec plus de descriptions et de contraintes. Par exemple, avec le prompt suivant, l'image obtenue sera plus spécifique.
|
||||
|
||||
```Plain
|
||||
"A hyper-realistic close-up of a fresh red apple with water droplets on its skin, sitting on a dark rustic wooden table. Cinematic dramatic lighting, rim light, shallow depth of field, bokeh background, 8k resolution, macro photography."
|
||||
```
|
||||
|
||||
|
||||
|
||||
Cliquez sur download dans la zone Output Image pour sauvegarder l'image localement.
|
||||
|
||||
|
||||
|
||||
### 1.3 Scénarios courants de génération d'assets avec les modèles de génération d'images
|
||||
|
||||
Dans la pratique professionnelle, la génération d'images par grands modèles est davantage utilisée pour **produire efficacement des assets de design** que pour créer des œuvres d'art uniques.
|
||||
|
||||
En observant les cas les plus populaires sur certains comptes de marketing liés au design, on constate que leur production se concentre principalement sur deux catégories de scénarios :
|
||||
|
||||
* **Texte vers image (de 0 à 1)**
|
||||
* **Image avec référence (de 1 à N)**
|
||||
|
||||
#### I. Texte vers image : obtenir rapidement du matériel de design
|
||||
|
||||
Cette catégorie de scénarios se concentre sur l'efficacité. Quand il faut combler des vides dans un design (états vides, avatars, illustrations), l'IA sert essentiellement de **banque d'images à génération instantanée**.
|
||||
|
||||
1. ##### Générer des assets de design UI
|
||||
|
||||
* Tendance : icônes 3D style glassmorphisme ou argile sur Dribbble
|
||||
* Manifestation courante : matériaux translucides, bords lumineux, icônes fonctionnelles ou météo aux couleurs bonbon
|
||||
|
||||
**Exemple de Prompt :**
|
||||
|
||||
> A set of 3D weather icons (sun, cloud, rain), glassmorphism style, frosted glass texture, soft pastel gradient colors, soft studio lighting, isometric view, transparent background, 4k.
|
||||
|
||||
|
||||
|
||||
2. ##### Générer des logos
|
||||
|
||||
* Tendance : logos tech minimalistes aux lignes épurées et combinaisons géométriques
|
||||
* Manifestation courante : palette noir et blanc, design en espace négatif, identité de marque affirmée
|
||||
|
||||
**Exemple de Prompt :**
|
||||
|
||||
> Minimalist vector logo design for a tech brand "Coffee Code", combining a coffee cup with coding brackets < >, flat design, solid black lines, white background, Paul Rand style, svg.
|
||||
|
||||
|
||||
|
||||
3. ##### Générer des images d'utilisateurs pour un site
|
||||
|
||||
* Tendance : avatars 3D virtuels courants sur les sites SaaS, pour éviter les problèmes de droits d'image de personnes réelles
|
||||
* Manifestation courante : expressions amicales, proportions cartoon, style Pixar ou Memoji
|
||||
|
||||
**Exemple de Prompt :**
|
||||
|
||||
> Close-up portrait of a friendly young tech professional, smiling, Memoji 3D style, clay render, bright colors, soft lighting, solid plain background, Pixar character design.
|
||||
|
||||
|
||||
|
||||
4. ##### Générer des illustrations d'articles
|
||||
|
||||
* Tendance : illustrations plates abstraites courantes dans les blogs d'entreprises tech
|
||||
* Manifestation courante : palette violet-bleu, proportions de personnages exagérées, éléments UI flottants
|
||||
|
||||
**Exemple de Prompt :**
|
||||
|
||||
> Editorial flat illustration representing remote work, a person sitting on a giant globe using a laptop, corporate memphis art style, vibrant colors (purple and teal), vector texture.
|
||||
|
||||
|
||||
|
||||
#### II. Image avec référence : maintenir la cohérence visuelle
|
||||
|
||||
Cette catégorie de scénarios se concentre davantage sur **l'extensibilité**. Quand vous avez déjà une image clé satisfaisante et devez générer un ensemble complet d'assets au style cohérent.
|
||||
|
||||
5. ##### Un ensemble de boutons ou d'assets d'interaction cohérents avec l'image principale
|
||||
|
||||
Dans le développement de jeux, la cohérence de l'UI est cruciale. Supposons que vous ayez déjà le bouton **« PLAY »** de l'interface principale et deviez maintenant créer un ensemble complet de boutons fonctionnels au style unifié (pause, paramètres, accueil). Dessiner à la main chaque bouton pour garantir une cohérence parfaite en termes de brillance, perspective et valeurs de couleur est très difficile.
|
||||
|
||||
**Processus de base :**
|
||||
|
||||
1. Sauvegarder l'image du bouton bleu « PLAY » existant
|
||||
|
||||
|
||||
|
||||
2. La glisser dans la zone **Input Image** comme modèle de référence pour les générations suivantes
|
||||
3. Garder la description de style du prompt inchangée, modifier uniquement le contenu principal
|
||||
|
||||
Avec ce processus, il suffit de remplacer la description du contenu pour obtenir des boutons aux fonctionnalités différentes mais au style cohérent.
|
||||
|
||||
**Exemple de Prompt :**
|
||||
|
||||
**Variante A : Bouton pause (icône)**
|
||||
|
||||
> A capsule-shaped game UI button with a white pause icon (two vertical bars) inside. Same glossy blue jelly style, shiny plastic texture, white thick outline, vector illustration, high quality.
|
||||
|
||||
|
||||
|
||||
**Variante B : Bouton paramètres (icône complexe)**
|
||||
|
||||
> A capsule-shaped game UI button with a white gear icon (settings symbol) inside. Same glossy blue jelly style, shiny plastic texture, white thick outline, vector illustration, high quality.
|
||||
|
||||
|
||||
|
||||
**Variante C : Bouton rejouer (changement de forme)**
|
||||
|
||||
Si vous devez ajuster la forme du bouton, décrivez-la directement dans le prompt — le modèle tentera de changer la structure tout en préservant les caractéristiques de matériau.
|
||||
|
||||
> A round game UI button with a white circular arrow icon (replay symbol) inside. Same glossy blue jelly style, shiny plastic texture, white thick outline, vector illustration, high quality.
|
||||
|
||||
|
||||
|
||||
Avec cette série d'opérations, vous pouvez non seulement remplacer la fonction et l'icône du bouton, mais même changer sa forme, tout en conservant une cohérence élevée en termes de matériau, de palette et de lumière parmi tous les résultats générés. C'est précisément la valeur centrale des grands modèles dans les scénarios de déclinaison d'assets de design.
|
||||
|
||||
## Chapitre 2 : Un assistant de génération d'images plus obéissant — l'exemple de Lovart
|
||||
|
||||
Dans la première partie, nous avons appelé NanoBanana directement via le code et avons expérimenté le flux de base « saisie = génération ». Cette approche fonctionne bien quand les besoins sont simples. Mais quand la tâche de génération commence à inclure plus de contraintes, par exemple :
|
||||
|
||||
* Besoin de plusieurs images au style cohérent
|
||||
* Besoin d'ajustements itératifs sur les résultats existants
|
||||
* Besoin de modifier dynamiquement la direction de génération en fonction des entrées utilisateur
|
||||
|
||||
L'approche par appel unique devient progressivement insuffisante.
|
||||
|
||||
C'est là qu'il faut introduire un **Agent AI (Intelligence artificielle)**. Cette section prend **Lovart** comme exemple pour montrer comment le flux de travail change lorsque le modèle de génération d'images acquiert une « couche de réflexion ». Notez bien ! Il ne s'agit pas de publicité, mais simplement de vous aider à comprendre rapidement la praticité des Agents AI.
|
||||
|
||||
### 2.0 Découvrir Lovart : votre agent de design AI
|
||||
|
||||
Lovart est un outil de design basé sur des Agents, disponible en web. Comparé aux outils de génération d'images classiques, il ajoute une couche de « réflexion et planification » avant la génération.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Une fois dans Lovart, voici les principaux éléments de contrôle à connaître :
|
||||
|
||||
#### Sélection du modèle
|
||||
|
||||
Cliquez sur l'icône du cube sous le champ de saisie pour voir les modèles de génération disponibles (comme GPT Image, Flux, etc.).
|
||||
|
||||
Pour rester cohérent avec l'exemple précédent, cette section utilise toujours NanoBanana comme modèle de génération sous-jacent.
|
||||
|
||||
|
||||
|
||||
#### Mode de réflexion
|
||||
|
||||
C'est le commutateur central de Lovart :
|
||||
|
||||
* **Fast Mode (⚡)** : proche de l'API native, réponse rapide, adapté à la génération d'images uniques avec des instructions claires
|
||||
* **Thinking Mode (💡)** : mode Agent, l'IA décompose d'abord le besoin, réécrit le prompt, puis exécute la génération
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Capacité de connexion Internet
|
||||
|
||||
En activant l'icône du globe, l'Agent peut rechercher des informations en ligne pendant la génération (tendances de design, palettes de couleurs, etc.) comme entrée complémentaire.
|
||||
|
||||
### 2.1 Pourquoi l'API native ne suffit-elle pas ?
|
||||
|
||||
Même s'il est déjà possible de générer des images de bonne qualité via Python, l'API native reste limitée pour les tâches complexes. La raison principale est que l'API native est fondamentalement impérative. Quand vous lui demandez de générer un objet spécifique, elle peut l'exécuter directement ; mais quand l'entrée devient « concevoir un ensemble complet d'assets de jeu », elle ne décompose pas spontanément l'objectif en étapes exécutables.
|
||||
|
||||
La différence fondamentale de Lovart réside dans le mécanisme d'Agent. Entre l'entrée utilisateur et le modèle de génération d'images, elle ajoute une couche de logique de compréhension et de planification : identifier d'abord l'intention de l'utilisateur, puis décomposer la tâche, réécrire le prompt, et enfin exécuter la génération.
|
||||
|
||||
### 2.2 Démonstration pratique : créer un ensemble de stickers d'IP en 5 minutes
|
||||
|
||||
Prenons l'exemple de **« créer un ensemble de stickers d'IP de canard programmeur »** pour voir comment l'Agent participe à l'ensemble du processus.
|
||||
|
||||
#### Phase 1 : Planification (capacité de réflexion de l'Agent)
|
||||
|
||||
**Problème de l'API native :**
|
||||
Vous devez penser vous-même au design du personnage, aux états émotionnels et écrire un prompt séparé pour chaque image.
|
||||
|
||||
**L'approche de Lovart :**
|
||||
|
||||
1. Activer le 💡 **Thinking Mode**
|
||||
2. Saisir une seule instruction :
|
||||
|
||||
> Concevoir un ensemble de stickers d'IP de canard programmeur, style flat design, mignon
|
||||
|
||||
L'IA ne dessine pas immédiatement. Elle va d'abord chercher sur Internet des images de design de canards programmeurs. Puis elle produit un plan décomposé, générant automatiquement des scènes comme Debug, Coffee Break, Panic, avec les descriptions visuelles correspondantes.
|
||||
|
||||
|
||||
|
||||
À cette étape, l'IA passe du rôle d'« exécutant » à celui de « planificateur ». Une fois que l'IA a analysé vos besoins, vous pouvez voir plusieurs styles et contenus d'images de canards programmeur dans la zone de canevas de Lovart. Vous pouvez commencer à filtrer les styles qui vous plaisent.
|
||||
|
||||
|
||||
|
||||
#### Phase 2 : Cohérence (ancrage visuel basé sur la référence)
|
||||
|
||||
Les images dans Lovart ne sont pas seulement des résultats, elles participent aussi aux générations suivantes.
|
||||
|
||||
##### Image de référence complète
|
||||
|
||||
* Sélectionnez le « canard standard » qui vous satisfait le plus dans les esquisses, cliquez sur l'image correspondante dans la zone de canevas
|
||||
* L'image apparaîtra automatiquement dans la zone de dialogue comme Reference
|
||||
|
||||
|
||||
|
||||
* Saisissez une nouvelle action (comme « heureux ») et générez
|
||||
|
||||
Le résultat généré héritera de la palette, des proportions et des détails du modèle original.
|
||||
|
||||
|
||||
|
||||
##### Référence partielle / Intégration multi-images
|
||||
|
||||
Outre l'utilisation d'une image complète comme référence, Lovart supporte aussi :
|
||||
|
||||
* **Sélectionner uniquement une zone partielle de l'image** (par exemple uniquement le chapeau ou l'expression)
|
||||
|
||||
Cliquez sur l'onglet à gauche de la zone de canevas, sélectionnez la touche « Mark », et marquez la zone partielle souhaitée sur l'image cible. Cette partie sera automatiquement synchronisée dans la zone de dialogue. Par exemple, ici nous pouvons choisir de modifier la couleur de fond.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
On peut voir que la nouvelle image générée n'a changé que la couleur de fond, ce qui correspond bien à notre demande.
|
||||
|
||||
* **Référencer des sous-éléments de plusieurs images** et les combiner pour générer un nouveau résultat
|
||||
|
||||
Par exemple : vous pouvez conserver le personnage principal de l'image A tout en remplaçant uniquement le chapeau par le style de l'image B. L'Agent intégrera automatiquement ces contraintes visuelles en arrière-plan.
|
||||
|
||||
Prenons l'exemple du canard programmeur : nous pouvons choisir de conserver l'image du canard de la première image et la remplacer dans la deuxième image comme élément principal.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
L'effet final est très significatif. Vous pouvez aussi essayer d'autres combinaisons !
|
||||
|
||||
#### Phase 3 : Livraison (appels d'outils de l'Agent)
|
||||
|
||||
Une fois la génération terminée, vous pouvez directement exécuter : agrandissement, suppression d'arrière-plan, effacement, etc.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Il ne s'agit pas de simples filtres, mais de résultats obtenus par l'Agent en调度ant automatiquement différents outils.
|
||||
|
||||
Une fois le style de base défini, il est très rapide de générer toute une série d'images de stickers.
|
||||
|
||||
|
||||
|
||||
Au final, nous obtenons des assets de qualité production directement livrables, et non pas de simples images de démonstration.
|
||||
|
||||
### 2.3 Informations sur l'utilisation et la tarification
|
||||
|
||||
Lovart utilise un modèle de tarification par abonnement, avec différents forfaits correspondant à différentes allocations d'utilisation et droits de fonctionnalité. Les détails sont disponibles sur le site officiel.
|
||||
|
||||
Ce tutoriel ne fait aucune recommandation ni comparaison de forfaits ; si vous avez un besoin en usage réel, vous pouvez choisir de passer à un forfait payant selon votre situation personnelle.
|
||||
Le paiement est actuellement possible via **Alipay** et d'autres méthodes.
|
||||
|
||||
|
||||
|
||||
#### Résumé
|
||||
|
||||
Lovart ne remplace pas le modèle sous-jacent, mais grâce au mécanisme d'Agent, fait évoluer la génération d'images de « l'exécution unique » vers un « flux de travail continu ».
|
||||
|
||||
Quand la tâche commence à impliquer de la planification, de la cohérence et de la livraison, l'avantage de ce type d'outils devient très évident.
|
||||
|
||||
## Chapitre 3 : Créer vous-même un assistant de dessin intelligent
|
||||
|
||||
Outre l'utilisation directe de Lovart, nous pouvons aussi implémenter nous-mêmes une version simplifiée d'un assistant de dessin.
|
||||
|
||||
Ce chapitre prend l'exemple de « l'illustration automatique d'articles » et construit progressivement un Agent avec des capacités de réflexion, en partant d'un problème concret.
|
||||
|
||||
### 3.1 Le problème : pourquoi envoyer directement un article à un modèle de dessin ne fonctionne pas ?
|
||||
|
||||
Envoyer directement un article long à NanoBanana en demandant une illustration donne rarement des résultats satisfaisants. La raison n'est pas que le modèle « dessine mal », mais qu'**il n'est pas doué pour comprendre les textes longs**.
|
||||
|
||||
Les modèles de génération d'images sont plus adaptés aux descriptions visuelles courtes et précises. Quand l'entrée devient un article avec sa structure, ses points clés et son contexte, le modèle ne peut pas déterminer quelles parties doivent vraiment être représentées dans l'image. Cela conduit souvent à des résultats hors sujet ou ne capturant que des détails épars, sans capacité de synthèse globale.
|
||||
|
||||
Fondamentalement, le modèle d'images n'a que la capacité d'« exécuter », mais manque d'un processus d'analyse et de sélection du texte.
|
||||
|
||||
|
||||
|
||||
### 3.2 Approche de résolution : séparer « compréhension » et « exécution » avec un Agent
|
||||
|
||||
Pour résoudre ce problème, la clé n'est pas des prompts plus complexes, mais **de réfléchir avant de dessiner**. Nous introduisons donc une « couche de réflexion » indépendante dans le flux de génération, et construisons un Agent minimal mais fonctionnel.
|
||||
|
||||
L'objectif principal de cet Agent est simple : **que l'image finale générée soit la plus proche possible de la véritable intention expressive de l'utilisateur.**
|
||||
|
||||
Le flux global peut se résumer ainsi : **Texte long en entrée → Modèle de langage pour compréhension et jugement → Génération d'un prompt visuel approprié → Modèle d'images pour la génération → Image en sortie**
|
||||
|
||||
|
||||
|
||||
Comment notre Agent peut-il comprendre l'intention de l'utilisateur ?
|
||||
|
||||
Nous choisissons de créer une « couche de réflexion » simplifiée, avec trois types d'intentions : entrée invalide, génération directe, texte long nécessitant compréhension.
|
||||
|
||||
Dans cet Agent, la répartition des rôles se résume en quatre points :
|
||||
|
||||
1. **Le modèle de langage comme cœur décisionnel**
|
||||
Il est responsable de la compréhension du contenu de l'article, du jugement de l'intention de l'entrée utilisateur, et de la répartition de la tâche vers le chemin de génération approprié, décidant « que faire ensuite » et comment générer le prompt de dessin.
|
||||
2. **Le modèle d'images comme exécutant**
|
||||
Le modèle d'images ne participe pas à la compréhension ni au jugement, il reçoit uniquement les instructions visuelles déjà préparées et se concentre sur le rendu d'image.
|
||||
3. **L'utilisateur comme guide intervenant**
|
||||
Outre la saisie directe de texte, l'utilisateur peut ajuster manuellement le prompt généré pendant le processus, ou ajouter une image de référence pour guider la génération, orientant et affinant ainsi le résultat final.
|
||||
4. **Gradio et l'API backend comme couche d'hébergement global**
|
||||
Ils sont responsables de la liaison entre l'interface, les appels de modèle et l'affichage des résultats, garantissant que l'Agent fonctionne de manière stable comme une application web complète.
|
||||
|
||||
|
||||
|
||||
### 3.3 Préparation pratique : obtenir les API
|
||||
|
||||
Cela a l'air intéressant, n'est-ce pas ! Pour exécuter le flux ci-dessus, nous n'avons besoin que de deux types d'API.
|
||||
|
||||
#### La main : API NanoBanana (génération d'images)
|
||||
|
||||
Réutilisez directement la clé API et l'URL API déjà configurées au chapitre 1, sans configuration supplémentaire.
|
||||
|
||||
#### Le cerveau : API SiliconFlow (réflexion textuelle)
|
||||
|
||||
Nous avons besoin d'un grand modèle de langage pour assurer la « couche de réflexion ». Ce tutoriel utilise le service de modèle fourni par SiliconFlow : [https://cloud.siliconflow.cn](https://cloud.siliconflow.cn/)
|
||||
|
||||
|
||||
|
||||
SiliconFlow fournit une interface compatible avec la spécification API OpenAI, très facile à appeler via des requêtes réseau standard dans votre projet. Nous choisissons ici le modèle gratuit Qwen2.5-7B-Instruct. Le contenu nécessaire pour l'appel est déjà intégré dans le Prompt ci-dessous. Avant de commencer, il vous suffit de créer un compte sur le site officiel et de générer une clé API.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Cette clé sera utilisée pour les appels de modèle ultérieurs.
|
||||
|
||||
### 3.4 Construire l'Agent :
|
||||
|
||||
Cette expérience utilise principalement Trae pour vous aider à écrire le code. Ce tutoriel utilise le modèle Gemini-3-Pro-Preview. L'idée générale est de créer un nouveau projet, de copier le Prompt complet ci-dessous dans la boîte de dialogue et de l'envoyer, de remplacer progressivement les clés API, puis d'exécuter le code et effectuer les tests.
|
||||
|
||||
|
||||
|
||||
#### Phase 1 : Framework de base Gradio Blocks et mise en page de l'interface
|
||||
|
||||
Dans cette phase, notre objectif principal est de construire d'abord une « apparence » pour l'Agent entier, en réalisant la conception de la page frontend. Copiez le Prompt ci-dessous dans la boîte de dialogue de Trae, et après implémentation, vous obtiendrez une URL locale (généralement http://127.0.0.1:7860) pour voir l'interface et vérifier le résultat.
|
||||
|
||||
```Plain
|
||||
Bloc 1 : Framework de base Gradio Blocks et mise en page de l'interface
|
||||
1. Objectif de la tâche
|
||||
· Basé sur la mise en page Blocks de Gradio 4.0.0+, implémenter l'interface de base du projet « LLM + Nanobanana texte vers image », en suivant strictement une disposition fixe gauche-droite, en initialisant tous les composants UI et en définissant les états initiaux corrects.
|
||||
|
||||
2. Exigences de la stack technique
|
||||
· Doit utiliser le mode Blocks de Gradio 4.0.0+, interdit le mode Interface ;
|
||||
· Dépendances : gradio>=4.0.0, pillow>=10.0.0 (import uniquement, pas encore de logique de traitement d'image) ;
|
||||
· Le code doit être un fichier Python complet et exécutable, incluant toutes les instructions d'import nécessaires.
|
||||
|
||||
3. Règles de mise en page de l'interface (contrainte principale, intégrant les détails pratiques)
|
||||
· Mise en page globale :
|
||||
Titre de la page : Outil complet de texte vers image piloté par LLM ;
|
||||
Disposition fixe gauche-droite : gauche occupe 60% de la largeur, droite 40%, utiliser gr.Row et gr.Column pour le contrôle des proportions.
|
||||
· Gauche 60% (zone du processus de génération de prompts) liste des composants :
|
||||
input_text : gr.Textbox, label « Texte d'entrée (paragraphe de tutoriel / instruction de dessin) », lines=6, placeholder « Veuillez entrer le texte de tutoriel nécessitant une illustration ou une instruction de dessin direct... » ;
|
||||
identify_intent_btn : gr.Button, value="Identifier l'intention", état initial normal cliquable ;
|
||||
intent_status : gr.Textbox, label « Type d'intention / Statut de traitement », lines=2, interactive=False, valeur initiale « Intention non identifiée » ;
|
||||
system_prompt : gr.Textbox, label « System Prompt (éditable uniquement pour l'intention d'illustration d'article) », lines=4, interactive=False, placeholder « Règles de contrainte pour la génération de prompts par le LLM... » ;
|
||||
confirm_prompt_btn : gr.Button, value="Confirmer la génération du prompt de dessin", interactive=False (désactivé initialement pour éviter les erreurs) ;
|
||||
generation_prompt : gr.Textbox, label « Prompt de dessin (éditable) », lines=3, interactive=True, valeur initiale vide, placeholder « Le prompt de dessin en anglais généré s'affichera ici, modification manuelle possible... ».
|
||||
· Droite 40% (zone de génération d'images Nanobanana) liste des composants :
|
||||
ref_image : gr.Image, label « Image de référence (optionnel, image vers image) », type=filepath, height=300, autorise l'upload ;
|
||||
generate_btn : gr.Button, value="Générer l'image", interactive=False (désactivé initialement, pas de prompt = pas de clic) ;
|
||||
result_image : gr.Image, label="Résultat de la génération", type=pil, height=300, initialement vide, interactive=False.
|
||||
|
||||
4. Exigences de logique d'interaction
|
||||
· L'état interactive initial de tous les composants suit strictement la configuration ci-dessus, mis à jour dynamiquement via des fonctions par la suite ;
|
||||
· L'état désactivé des boutons doit être visuel (grisé), pour éviter les erreurs de manipulation.
|
||||
|
||||
5. Exigences de sortie
|
||||
· Générer un code Python complet, implémentant uniquement la mise en page de l'interface et l'initialisation des composants, sans aucune logique métier ;
|
||||
· Commentaires de code clairs, noms de composants cohérents avec la version pratique (input_text/identify_intent_btn etc.) ;
|
||||
· Le code doit être directement exécutable, la structure de l'interface doit correspondre exactement à la description.
|
||||
```
|
||||
|
||||
Après avoir ouvert http://127.0.0.1:7860 dans le navigateur, vous verrez que Trae a généré la page web suivante selon nos exigences, globalement conforme — vous pouvez passer à l'étape suivante de génération.
|
||||
|
||||
|
||||
|
||||
#### Phase 2 : Module d'identification d'intention par LLM (API Siliconflow)
|
||||
|
||||
Dans l'utilisation quotidienne de VLM pour le dessin, il existe trois types d'entrées courantes :
|
||||
|
||||
1. Contenu sans signification, comme « bonjour », « as-tu mangé aujourd'hui », impossible d'en tirer une image.
|
||||
2. Article/texte long, avec un nombre de mots important, comme un article structuré d'environ 200 mots, nécessitant d'abord de comprendre la structure et le contenu de l'article avant de réfléchir à la génération d'une image résumant ce texte.
|
||||
3. Instruction de dessin direct, comme « dessine-moi un chien qui prend un bain », où la demande est déjà très spécifique et l'image peut être générée directement.
|
||||
|
||||
Comme précédemment, copiez le Prompt ci-dessous dans la boîte de dialogue de Trae et ajoutez les API obtenues aux étapes précédentes.
|
||||
|
||||
```Plain
|
||||
Bloc 2 : Module d'identification d'intention par LLM (API Siliconflow)
|
||||
1. Objectif de la tâche
|
||||
Sur la base de l'interface Gradio déjà implémentée, ajouter la logique de clic au bouton « Identifier l'intention », appeler l'API Siliconflow pour l'identification d'intention et lier l'état des composants.
|
||||
|
||||
2. Exigences de la stack technique
|
||||
Basé sur Gradio 4.0.0+ Blocks ;
|
||||
Dépendances : requests>=2.31.0, openai ;
|
||||
Sortie : fichier Python complet et exécutable, incluant l'interface du Bloc 1 + la logique de ce module.
|
||||
|
||||
3. Règles métier principales (à ne jamais transgresser)
|
||||
· Règles de classification d'intention (3 types uniquement, retourner strictement un nombre + description)
|
||||
1 = Contenu sans signification : simple bavardage, salutations, conversation hors sujet, sans aucun besoin de dessin ou d'illustration (comme « bonjour » « as-tu mangé ») ;
|
||||
2 = Besoin d'illustration pour article/texte long : l'utilisateur entre un article complet, un tutoriel, un paragraphe, un texte explicatif, au contenu plutôt narratif/explicatif/pédagogique, impliquant implicitement la nécessité de générer une illustration pour ce contenu, sans que l'utilisateur dise explicitement « illustre ce texte » ;
|
||||
3 = Instruction de dessin direct : l'utilisateur entre une commande de dessin courte et claire, sans contexte de texte long, demandant directement de dessiner quelque chose (comme « dessine un chat style Apple »).
|
||||
· Contraintes d'appel LLM (intégrant le template de la version pratique)
|
||||
URL de l'interface : https://api.siliconflow.cn/v1/chat/completions ;
|
||||
Modèle : Qwen/Qwen2.5-7B-Instruct ;
|
||||
temperature=0.1 ;
|
||||
Définition uniforme du code :
|
||||
python
|
||||
LLM_BASE_URL = "https://api.siliconflow.cn/v1"
|
||||
LLM_API_KEY = "" # L'utilisateur remplace lui-même
|
||||
LLM_MODEL = "Qwen/Qwen2.5-7B-Instruct"
|
||||
# Template d'identification d'intention validé en pratique (figé dans le code)
|
||||
INTENT_PROMPT_TEMPLATE = """Vous devez identifier l'intention du texte saisi par l'utilisateur, ne retourner qu'un des 3 types de résultats suivants (format : nombre + description en français) :
|
||||
1 = Contenu sans signification ; 2 = Besoin d'illustration pour article/texte long ; 3 = Instruction de dessin direct.
|
||||
|
||||
Texte de l'utilisateur : {user_input}
|
||||
|
||||
Résultat de l'identification :
|
||||
Extraire uniquement le nombre et la description du résultat, interdit tout contenu supplémentaire."""
|
||||
|
||||
4. Règles de liaison des composants
|
||||
· Résultat 1 : intent_status affiche « 1 = Contenu sans signification : aucun besoin de dessin », system_prompt reste désactivé, confirm_prompt_btn désactivé ;
|
||||
· Résultat 2 : intent_status affiche « 2 = Besoin d'illustration pour article/texte long : générer une illustration pour le contenu saisi », activer system_prompt et remplir la règle par défaut, activer confirm_prompt_btn ;
|
||||
· Résultat 3 : intent_status affiche « 3 = Instruction de dessin direct : générer une image selon l'instruction », system_prompt désactivé et rempli avec la règle par défaut, activer confirm_prompt_btn.
|
||||
|
||||
5. Gestion des exceptions
|
||||
Exceptions API, exceptions de parsing : afficher un message convivial, pas de crash, les composants reviennent à l'état initial.
|
||||
|
||||
6. Exigences de sortie
|
||||
Générer un code complet et exécutable, il suffit de remplacer LLM_API_KEY pour l'utiliser, logique claire et commentaires complets, template d'identification d'intention strictement conforme à la version pratique.
|
||||
```
|
||||
|
||||
Rafraîchissez l'URL http://127.0.0.1:7860 précédente et commencez à tester si les trois cas sont correctement détectés.
|
||||
|
||||
1. Contenu sans signification : essayez de saisir « bonjour », « merci », etc. — la détection fonctionne correctement.
|
||||
|
||||
|
||||
|
||||
2. Article/texte long : ici nous avons utilisé un texte généré par Doubao décrivant l'intelligence artificielle. Vous pouvez aussi tester avec vos propres paragraphes de thèse.
|
||||
|
||||
```Plain
|
||||
L'intelligence artificielle remodelle l'écosystème éducatif avec une profondeur et une ampleur sans précédent. Grâce à des algorithmes d'apprentissage adaptatif, les systèmes IA peuvent construire la carte cognitive de chaque étudiant, suivre en temps réel la trajectoire de maîtrise des connaissances, et ajuster dynamiquement le niveau de difficulté et le mode de présentation du contenu pédagogique. Dans un environnement de classe traditionnel, les enseignants peinent souvent à satisfaire simultanément les besoins d'étudiants aux styles d'apprentissage et niveaux de capacité différents, tandis que les plateformes éducatives basées sur l'apprentissage profond peuvent analyser les schémas de comportement des étudiants dans les simulations interactives, identifier les obstacles subtils dans la compréhension de concepts complexes comme la mécanique quantique ou le calcul, et fournir des échafaudages cognitifs précis.
|
||||
|
||||
Les tuteurs virtuels pilotés par des moteurs avancés de traitement du langage naturel peuvent non seulement déconstruire des questions ouvertes, comme « comment évaluer l'impact de la Révolution française sur les systèmes démocratiques modernes », mais aussi guider des dialogues socratiques stimulant la pensée critique. Lorsqu'un étudiant rédige un essai sur l'impact du changement climatique sur les écosystèmes polaires, l'assistant d'écriture IA peut analyser la rigueur logique de son argumentation, pointer les problèmes d'actualité dans les références de données, et suggérer des termes scientifiques plus précis. Dans le domaine de l'éducation spécialisée, la vision par ordinateur permet à l'IA d'identifier les indices non verbaux des enfants du spectre autistique dans les interactions sociales, ajuster les stratégies d'intervention, tandis que les algorithmes de calcul affectif aident à détecter la frustration lors de l'apprentissage en ligne, fournissant en temps utile des retours encourageants.
|
||||
|
||||
Cependant, cette intégration technologique soulève une série de dilemmes éthiques. Les biais algorithmiques peuvent involontairement marginaliser les étudiants de certains contextes culturels, les questions de transparence dans la collecte de données soulèvent des préoccupations concernant la vie privée académique, et la dépendance excessive aux systèmes de notation automatisés peut affaiblir la compréhension approfondie des enseignants sur le processus de pensée des étudiants. Plus complexe encore, quand l'IA commence à générer des expériences de laboratoire virtuel hautement réalistes, nous devons redéfinir la valeur de « l'expérience pratique » dans l'éducation. Le paradigme éducatif futur pourrait évoluer vers des enseignants humains se concentrant sur le développement de la créativité, de l'empathie et du jugement moral, tandis que les systèmes IA assumeraient les fonctions de transmission des connaissances, d'entraînement aux compétences et d'évaluation personnalisée, formant un symbiote éducatif en co-évolution, exploitant à la fois les avantages computationnels des machines et conservant la chaleur unique de l'éducation humaine.
|
||||
```
|
||||
|
||||
Détection réussie également !
|
||||
|
||||
|
||||
|
||||
3. Instruction de dessin direct : ici nous avons saisi « je veux dessiner un chat », détecté avec précision.
|
||||
|
||||
|
||||
|
||||
Nous avons ainsi réussi à implémenter la deuxième phase — l'identification d'intention.
|
||||
|
||||
#### Phase 3 : Module de génération de prompts de dessin (second appel LLM)
|
||||
|
||||
Après l'identification d'intention, pour les articles ou textes longs, il reste une étape très importante : générer le prompt de dessin, et c'est précisément le point clé de cet Agent.
|
||||
|
||||
```SQL
|
||||
Bloc 3 : Module de génération de prompts de dessin (second appel LLM)
|
||||
1. Objectif de la tâche
|
||||
Sur la base de l'identification d'intention, implémenter la logique du bouton « Confirmer la génération du prompt de dessin », appeler le LLM pour optimiser le texte en un prompt visuel en anglais adapté au dessin, remplir la zone d'édition et lier le bouton « Générer l'image ».
|
||||
|
||||
2. Exigences de la stack technique
|
||||
Identiques au Bloc 2, sortie : code complet = Bloc 1 + Bloc 2 + ce module ;
|
||||
Partage les LLM_BASE_URL, LLM_API_KEY, LLM_MODEL définis au Bloc 2, pas de nouvelle clé.
|
||||
|
||||
3. Règles métier principales (intégrant la logique d'assemblage de Prompt de la version pratique)
|
||||
· Règles d'entrée pour la génération de prompts (à suivre strictement)
|
||||
La génération de prompts de dessin n'est plus une simple concaténation de chaînes, mais construit une liste standard de messages Chat, la structure du code est la suivante :
|
||||
python
|
||||
messages=[
|
||||
# Rôle System : contenu system_prompt final confirmé/édité par l'utilisateur sur la page
|
||||
{"role": "system", "content": final_system_prompt},
|
||||
# Rôle User : porte les données à traiter, clarifie l'objectif de la tâche
|
||||
{"role": "user", "content": f"Veuillez générer un prompt visuel pour le contenu suivant :\n\n{user_input}"}
|
||||
]
|
||||
Intention 2 : le contenu System prend la version finale du system_prompt édité par l'utilisateur ;
|
||||
Intention 3 : le contenu System prend la règle par défaut remplie en état désactivé ;
|
||||
user_input est le texte original entré par l'utilisateur dans la zone input_text.
|
||||
|
||||
· Preset System Prompt validé en pratique (figé dans le code)
|
||||
python
|
||||
SYSTEM_PROMPT_DEFAULT = """Vous êtes maintenant un assistant créant des prompts de dessin pour NanoBanana.
|
||||
Vous devez traiter en fonction de mon contenu, l'image doit pouvoir expliquer ce dont parle ce passage, et faire comprendre à tous la structure globale et le sens général du texte.
|
||||
Il peut y avoir des éléments similaires à des présentations PPT (par exemple : le coin supérieur gauche montre l'idée centrale, le coin inférieur droit montre les données).
|
||||
Exigences de style de design : minimaliste, philosophie de design Apple (Apple Design Philosophy).
|
||||
Contrainte : retournez uniquement le prompt en anglais utilisable par NanoBanana, sans aucune explication, préfixe ou texte superflu."""
|
||||
|
||||
· Contraintes d'appel LLM
|
||||
Partage les mêmes LLM_BASE_URL, LLM_API_KEY, LLM_MODEL que le Bloc 2 ;
|
||||
temperature=0.7 (pour garantir la créativité et l'adaptabilité du prompt) ;
|
||||
max_tokens=200 (limiter la longueur de sortie, en adéquation avec la contrainte de prompt) ;
|
||||
Utiliser strictement la structure de liste de messages Chat standard ci-dessus, interdire la concaténation de chaînes.
|
||||
|
||||
· Contraintes forcées de sortie du prompt
|
||||
Uniquement en anglais, pas de chinois ;
|
||||
Doit inclure Apple Design Philosophy/Apple style + 1024x1024 ;
|
||||
Longueur 50–200 caractères, validation dans le code ;
|
||||
Pas d'explication supplémentaire, préfixe ou texte superflu, retourner uniquement le prompt lui-même.
|
||||
|
||||
4. Règles de liaison des composants
|
||||
Génération réussie : remplir le prompt dans la zone generation_prompt, activer generate_btn, intent_status ajoute « Prompt généré avec succès, modifiable avant génération d'image » ;
|
||||
Échec de génération : indiquer la raison spécifique (comme échec d'appel API, longueur insuffisante), generate_btn reste désactivé, zone generation_prompt vide ;
|
||||
Modification/vidage manuel de la zone generation_prompt par l'utilisateur :
|
||||
Si vidé, generate_btn est automatiquement désactivé ;
|
||||
Si non vide, generate_btn reste activé.
|
||||
|
||||
5. Gestion des exceptions
|
||||
Échec d'appel API : message convivial « Échec de génération du prompt : {message d'erreur spécifique} », pas de crash ;
|
||||
Échec de validation du prompt : indiquer clairement la raison (comme « ne contient pas Apple style », « longueur de seulement 40 caractères »), permettre de réessayer ;
|
||||
Échec de parsing de réponse : indiquer « Impossible d'analyser le résultat du LLM, veuillez réessayer ».
|
||||
|
||||
6. Exigences de sortie
|
||||
Code complet et exécutable, il suffit de remplacer LLM_API_KEY pour l'utiliser ;
|
||||
Structure de code claire, commentaires complets, interface belle et épurée ;
|
||||
Implémenter strictement la structure de liste de messages Chat standard, paramètres et logique d'exemple cohérents ;
|
||||
Inclure la logique de validation de longueur et de contenu du prompt, messages d'erreur conviviaux.
|
||||
```
|
||||
|
||||
Testez de la même manière avec le texte de la deuxième phase.
|
||||
|
||||
Notez que le System Prompt prédéfini pour la génération de prompts de dessin est le suivant :
|
||||
|
||||
> Vous êtes maintenant un assistant créant des prompts de dessin pour NanoBanana.
|
||||
> Vous devez traiter en fonction de mon contenu, l'image doit pouvoir expliquer ce dont parle ce passage, et faire comprendre à tous la structure globale et le sens général du texte.
|
||||
> Il peut y avoir des éléments similaires à des présentations PPT (par exemple : le coin supérieur gauche montre l'idée centrale, le coin inférieur droit montre les données).
|
||||
> Exigences de style de design : minimaliste, philosophie de design Apple (Apple Design Philosophy).
|
||||
> Contrainte : retournez uniquement le prompt en anglais utilisable par NanoBanana, sans aucune explication, préfixe ou texte superflu.
|
||||
|
||||
Si vous souhaitez changer de template prédéfini, vous pouvez modifier le prompt précédent, ou le modifier directement dans Trae via le dialogue.
|
||||
|
||||
|
||||
|
||||
Outre la modification du code sous-jacent, vous pouvez aussi éditer rapidement sur la page web. Par exemple, j'ai ajouté ici « ajoutez "Pic Prompt" au début », et on peut voir que le nouveau prompt généré inclut bien ce préfixe. Cette conception permet de modifier rapidement le System Prompt de génération de prompts, facilitant les changements de style.
|
||||
|
||||
|
||||
|
||||
#### Phase 4 : Module de génération texte vers image / image vers image Nanobanana
|
||||
|
||||
Enfin la dernière étape — sans intégrer le modèle de génération d'images, ce n'est pas un Agent complet !
|
||||
|
||||
```Bash
|
||||
Bloc 4 : Module de génération texte vers image / image vers image Nanobanana (version finale)
|
||||
1. Objectif de la tâche
|
||||
Implémenter la logique du bouton « Générer l'image », appeler la véritable API Nanobanana, supporter texte vers image / image vers image, parser le Base64 et afficher l'image.
|
||||
|
||||
2. Exigences de la stack technique
|
||||
Basé sur Gradio 4.0.0+ Blocks ;
|
||||
Dépendances : requests, pillow, base64, io, re ;
|
||||
Code complet = Bloc 1+2+3 + ce module.
|
||||
|
||||
3. Configuration API principale (figée et validée en pratique)
|
||||
Configuration figée dans le code :
|
||||
python
|
||||
# Configuration API figée dans le code
|
||||
NANOBANANA_API_URL = "https://api.zyai.online/v1/chat/completions"
|
||||
NANOBANANA_MODEL = "gemini-2.5-flash-image"
|
||||
NANOBANANA_API_KEY = "" # L'utilisateur remplace lui-même
|
||||
Méthode d'authentification : Header Authorization: Bearer {NANOBANANA_API_KEY}.
|
||||
|
||||
4. Exigences de prétraitement d'image (obligatoire)
|
||||
Implémenter la fonction image_to_base64_data_uri (ref_image_path), logique principale :
|
||||
Convertir l'image PIL en format PNG ;
|
||||
Mise à l'échelle automatique en résolution 1024x1024 ;
|
||||
Canal transparent converti en fond blanc ;
|
||||
Encoder en Base64, format retourné : data:image/png;base64,...
|
||||
|
||||
5. Règles de construction de la requête (suivre strictement la logique de branchement de la version pratique)
|
||||
· Définition de la fonction principale
|
||||
Implémenter la fonction generate_image (prompt, ref_image_path) :
|
||||
Paramètres d'entrée : prompt (contenu de la zone generation_prompt), ref_image_path (chemin du fichier uploadé dans ref_image) ;
|
||||
Retour : PIL Image (affichée dans result_image) ou message d'erreur.
|
||||
· Branche logique 1 : texte vers image pur (ref_image_path vide)
|
||||
python
|
||||
messages = [{"role": "user", "content": prompt}]
|
||||
· Branche logique 2 : image vers image (ref_image_path non vide)
|
||||
python
|
||||
# D'abord appeler la fonction de prétraitement d'image
|
||||
image_base64 = image_to_base64_data_uri(ref_image_path)
|
||||
messages = [{"role": "user","content": [{"type": "text", "text": prompt},{"type": "image_url", "image_url": {"url": image_base64}}]}]
|
||||
|
||||
6. Exigences de parsing de réponse (doit être compatible avec deux formats)
|
||||
Extraire l'image Base64 depuis choices[0].message.content, supporter :
|
||||
Champ image_url du retour JSON structuré ;
|
||||
Format Markdown ;
|
||||
Extraire uniformément l'encodage Base64, décoder puis convertir en PIL Image pour le retour.
|
||||
|
||||
7. Liaison des composants et gestion des exceptions
|
||||
Génération réussie : afficher la PIL Image dans result_image, intent_status indique « Image générée avec succès » ;
|
||||
Échec de génération/parsing/upload : afficher un message textuel clair dans intent_status (comme « Échec du parsing Base64 », « Délai d'attente de l'appel API dépassé »), pas de crash.
|
||||
|
||||
8. Exigences de sortie
|
||||
Code complet et exécutable, il suffit de remplacer LLM_API_KEY et NANOBANANA_API_KEY pour l'exécuter directement, flux complet utilisable, logique de branchement strictement conforme à la version pratique.
|
||||
```
|
||||
|
||||
|
||||
|
||||
C'est vraiment passionnant ! Nous avons enfin réussi à générer la première image de cet Agent. Regardez attentivement l'image générée — elle correspond bien à notre texte et à notre prompt. Vous avez maintenant pratiquement implémenté votre propre Agent !
|
||||
|
||||
|
||||
|
||||
Nous avons aussi ajouté la fonctionnalité image vers image : uploadez une image que vous aimez et l'IA s'en inspirera automatiquement pour le style.
|
||||
|
||||
|
||||
|
||||
Il convient de mentionner que les prompts générés aux étapes précédentes sont également éditables sur la page web, et c'est le prompt au moment du clic final sur le bouton qui fait foi. Même si je remplace ici par « a cute cat », l'image finale générée ne sera qu'un mignon petit chat.
|
||||
|
||||
## Chapitre 4 : Résumé
|
||||
|
||||
|
||||
|
||||
**Hourra ! C'est enfin terminé.**
|
||||
Honnêtement, même moi j'ai poussé un soupir de soulagement en écrivant la dernière ligne, alors imaginez pour vous qui avez suivi jusqu'au bout. Réussir à exécuter ce flux complet en entier est déjà très impressionnant — cela prouve que vous avez vraiment mis les mains sur le clavier et accompli les choses étape par étape. Bravo !
|
||||
|
||||
En écrivant ce contenu, je me suis toujours demandé ce que nous devions laisser derrière nous. La réponse n'est ni le nom des modèles, ni les paramètres ou une approche fixe, mais plutôt de vous aider à développer progressivement un ressenti : quelles tâches peut-on confier en toute sécurité à l'IA pour la compréhension et la planification, et où avez-vous simplement besoin de décider de la direction. Une fois cette répartition des rôles établie, de nombreux flux de génération qui semblaient complexes commencent à devenir plus fluides.
|
||||
|
||||
En y regardant en arrière, le chemin n'est pas si complexe. Réfléchissez clairement au problème que vous voulez résoudre, confiez les textes longs au modèle de langage pour les décomposer, puis transmettez l'intention visuelle organisée au modèle de dessin pour le rendu, et enfin encapsulez l'ensemble de ce flux dans votre propre petit assistant. À ce stade, vous ne faites plus qu'« utiliser un modèle » — vous construisez un système qui peut vous accompagner durablement dans votre travail. C'est exactement ce que ce tutoriel voulait vous transmettre avant tout.
|
||||
|
||||
Mais vous avez déjà fait du excellent travail ! Si vous êtes arrivé jusqu'ici, vous maîtrisez probablement les bases du Vibe Coding. Accordez-vous une petite pause bien méritée !
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="Articles connexes"
|
||||
description="Si vous souhaitez intégrer véritablement la « génération d'assets » dans un flux produit, vous pouvez continuer avec ces chapitres."
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1,465 @@
|
||||
# Mettre à jour votre interface avec une bibliothèque de composants moderne
|
||||
|
||||
Dans les cours précédents, vous avez appris à utiliser des outils de conception pour créer des interfaces, à convertir des maquettes en code avec un IDE AI, et même à réaliser un projet frontend complet. Mais vous avez peut-être remarqué un problème : les boutons, formulaires et boîtes de dialogue écrits de zéro fonctionnent, mais semblent toujours manquer de quelque chose par rapport aux « produits professionnels » — styles pas assez uniformes, détails d'interaction pas assez fluides, et l'adaptation à différents écrans est un vrai casse-tête.
|
||||
|
||||
C'est exactement le problème que les **bibliothèques de composants** résolvent.
|
||||
|
||||
Une bibliothèque de composants est un ensemble d'éléments UI pré-conçus et pré-développés. Boutons, champs de saisie, menus déroulants, boîtes de dialogue, tableaux... tous ces éléments d'interface que vous utilisez à répétition dans n'importe quel produit sont déjà prêts dans la bibliothèque, testés et affinés par un grand nombre d'utilisateurs. Il vous suffit de les combiner comme des briques Lego pour construire rapidement des interfaces de niveau professionnel.
|
||||
|
||||
## Ce que vous allez apprendre
|
||||
|
||||
1. Comprendre ce qu'est une bibliothèque de composants frontend et pourquoi le développement moderne l'utilise presque systématiquement
|
||||
2. Découvrir quatre bibliothèques de composants représentatives et comprendre leurs scénarios de prédilection
|
||||
3. À travers trois scénarios pratiques (landing page, page produit, back-office), apprendre le Vibe Coding avec IDE AI + bibliothèque de composants
|
||||
4. Apprendre à lire la documentation des bibliothèques de composants, trouver les composants appropriés et les utiliser correctement
|
||||
|
||||
## 1. Pourquoi a-t-on besoin de bibliothèques de composants ?
|
||||
|
||||
Imaginez que vous rénovez une maison. Vous pouvez fabriquer une chaise vous-même à partir de bois brut, mais l'approche la plus courante est d'en acheter une chez Ikea — design agréable, qualité stable, mode d'emploi clair, il suffit de l'assembler à la maison.
|
||||
|
||||
La bibliothèque de composants, c'est le « Ikea » du développement frontend. Elle ne fournit pas des meubles, mais des éléments d'interface :
|
||||
|
||||
| Écriture manuelle | Utilisation d'une bibliothèque de composants |
|
||||
| :--- | :--- |
|
||||
| Vous devez gérer vous-même les styles, interactions et animations | Prêt à l'emploi, styles et interactions déjà affinés |
|
||||
| Les boutons de différentes pages peuvent avoir des apparences différentes | Style global unifié, cohérence automatique |
|
||||
| L'adaptation mobile et tablette nécessite un travail supplémentaire | La plupart des bibliothèques intègrent le support responsive |
|
||||
| L'accessibilité est souvent oubliée | Les bibliothèques professionnelles gèrent la navigation clavier, les lecteurs d'écran, etc. |
|
||||
| Développement lent | Développement rapide, concentration sur la logique métier |
|
||||
|
||||
En résumé : **les bibliothèques de composants vous permettent de consacrer votre temps à « quoi faire » plutôt qu'à « comment dessiner ».**
|
||||
|
||||
### Voir pour croire : le même besoin, avec ou sans bibliothèque de composants
|
||||
|
||||
La théorie seule n'est pas convaincante. Utilisons un besoin presque identique dans Trae, en spécifiant ou non une bibliothèque de composants, pour voir la différence.
|
||||
|
||||
**Prompt 1 : Sans bibliothèque de composants**
|
||||
|
||||
```text
|
||||
Aidez-moi à créer une page de tableau de bord pour un assistant d'écriture AI, comprenant :
|
||||
- Barre de titre supérieure et bouton d'export
|
||||
- Quatre cartes statistiques affichant le nombre d'utilisateurs, d'utilisateurs actifs, de documents et de revenus, avec les tendances hausses/baisses
|
||||
- Un graphique en courbes et un graphique en secteurs
|
||||
- Tableau de liste d'utilisateurs avec pagination
|
||||
- Barre latérale de navigation à gauche
|
||||
```
|
||||
|
||||
Résultat dans Trae :
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran du tableau de bord généré sans bibliothèque de composants dans Trae -->
|
||||
<!--  -->
|
||||
|
||||
**Prompt 2 : Avec la bibliothèque de composants shadcn/ui**
|
||||
|
||||
```text
|
||||
Aidez-moi à créer une page de tableau de bord pour un assistant d'écriture AI, en utilisant la bibliothèque de composants shadcn/ui, comprenant :
|
||||
- Barre de titre supérieure et bouton d'export
|
||||
- Quatre cartes statistiques affichant le nombre d'utilisateurs, d'utilisateurs actifs, de documents et de revenus, avec les tendances hausses/baisses
|
||||
- Un graphique en courbes et un graphique en secteurs
|
||||
- Tableau de liste d'utilisateurs avec pagination
|
||||
- Barre latérale de navigation à gauche
|
||||
```
|
||||
|
||||
Résultat dans Trae :
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran du tableau de bord généré avec shadcn/ui dans Trae -->
|
||||
<!--  -->
|
||||
|
||||
Le même besoin, la seule différence étant l'ajout de `shadcn/ui + Tailwind CSS` au début du prompt. Le résultat généré par Trae est à un niveau complètement différent en termes de cohérence visuelle, de détails d'interaction et de finition globale. C'est la « mise à niveau gratuite » qu'apporte la bibliothèque de composants — il vous suffit d'ajouter un nom de bibliothèque de composants dans votre prompt.
|
||||
|
||||
## 2. Découvrir quatre bibliothèques de composants clés
|
||||
|
||||
Les bibliothèques de composants sont nombreuses (voir la liste complète en [Annexe](#annexe-apercu-de-plus-de-bibliotheques-de-composants)), mais il vous suffit d'abord de connaître ces quatre plus représentatives :
|
||||
|
||||
| Bibliothèque | Framework | Positionnement en une phrase | Site officiel |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [Ant Design](https://ant.design) | React | Produit par Ant Group, standard de facto pour les back-offices d'entreprise, couverture de composants extrêmement large | ant.design |
|
||||
| [shadcn/ui](https://ui.shadcn.com) | React | Pas d'installation npm, copie directe du code dans votre projet, basé sur Tailwind CSS, liberté de personnalisation maximale | ui.shadcn.com |
|
||||
| [HeroUI](https://heroui.com) (anciennement NextUI) | React | Styles par défaut élégants, animations fluides, idéal pour les landing pages et vitrines produits exigeantes visuellement | heroui.com |
|
||||
| [Material UI](https://mui.com) | React | La bibliothèque de composants React la plus ancienne, implémente les guidelines Material Design de Google, écosystème le plus mature | mui.com |
|
||||
|
||||
> Les utilisateurs de Vue ont également un choix riche : [Element Plus](https://element-plus.org) (la plus populaire en Chine), [Ant Design Vue](https://antdv.com), [Naive UI](https://www.naiveui.com) etc., voir [Annexe](#annexe-apercu-de-plus-de-bibliotheques-de-composants).
|
||||
|
||||
Différentes bibliothèques excellent dans différents scénarios. Découvrons à travers trois scénarios de développement réels comment pratiquer le Vibe Coding avec IDE AI + bibliothèque de composants.
|
||||
|
||||
Pour montrer les styles et caractéristiques de différentes bibliothèques, nous avons délibérément utilisé une bibliothèque différente dans chaque scénario. Mais attention : **c'est uniquement pour vous faire découvrir plusieurs approches**. En développement réel, vous pouvez tout à fait n'utiliser que celle que vous maîtrisez le mieux. Si vous aimez le style de shadcn/ui, vous pouvez l'utiliser pour des landing pages, des pages produit et des back-offices. Choisir une bibliothèque que vous trouvez belle et agréable à utiliser est plus important que tout le reste.
|
||||
|
||||
## 3. Pratique 1 : Construire une landing page produit avec HeroUI
|
||||
|
||||
**Scénario** : Vous avez créé un produit d'assistant d'écriture AI et avez besoin d'une belle landing page pour présenter les fonctionnalités du produit et attirer les inscriptions. La landing page doit avoir un fort impact visuel, des animations fluides et être belle sur mobile.
|
||||
|
||||
**Pourquoi choisir HeroUI** : Les styles par défaut de HeroUI sont déjà élégants, avec des animations de transition fluides intégrées, parfaitement adaptés aux pages vitrines orientées utilisateur.
|
||||
|
||||
### 3.1 Créer le projet
|
||||
|
||||
```bash
|
||||
# Créer le projet avec le CLI officiel HeroUI
|
||||
npx create-heroui-app@latest ai-writer-landing
|
||||
cd ai-writer-landing
|
||||
npm install
|
||||
```
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran du site HeroUI ou de la présentation des composants -->
|
||||
<!--  -->
|
||||
|
||||
### 3.2 Générer la landing page avec l'IDE AI
|
||||
|
||||
Ouvrez l'IDE AI (Cursor, Trae, etc.) et entrez dans le dialogue :
|
||||
|
||||
```text
|
||||
Aidez-moi à créer une landing page pour un assistant d'écriture AI, en utilisant la bibliothèque de composants HeroUI :
|
||||
|
||||
**Structure de la page :**
|
||||
1. Barre de navigation supérieure : Logo et nom du produit à gauche, trois liens « Fonctionnalités », « Tarifs », « À propos » à droite, plus un bouton « Commencer »
|
||||
2. Section hero : Grand titre « L'IA devient votre partenaire d'écriture », sous-titre présentant la valeur du produit, deux boutons « Essai gratuit » et « Voir la démo », une capture d'écran du produit en dessous
|
||||
3. Présentation des fonctionnalités : Trois cartes en colonnes, présentant respectivement « Continuation intelligente », « Ajustement de style », « Traduction multilingue », chaque carte avec icône, titre et description
|
||||
4. Section tarifs : Trois cartes de prix (version gratuite, version pro, version équipe), la version pro mise en évidence comme recommandée
|
||||
5. Appel à l'action en bas : Un slogan accrocheur avec un bouton d'inscription
|
||||
6. Pied de page : Informations de copyright et liens vers les réseaux sociaux
|
||||
|
||||
**Exigences de design :**
|
||||
- Aspect moderne et professionnel
|
||||
- Support du mode sombre
|
||||
- Doit être beau sur mobile
|
||||
```
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran du processus de génération de landing page par l'IDE AI ou du résultat -->
|
||||
<!--  -->
|
||||
|
||||
### 3.3 Composants clés utilisés par l'IA
|
||||
|
||||
Dans le code généré par l'IA, vous verrez ces composants HeroUI :
|
||||
|
||||
```jsx
|
||||
import {
|
||||
Navbar, NavbarBrand, NavbarContent, NavbarItem,
|
||||
Button,
|
||||
Card, CardHeader, CardBody, CardFooter,
|
||||
Divider,
|
||||
Link,
|
||||
Chip
|
||||
} from '@heroui/react'
|
||||
```
|
||||
|
||||
Le rôle de chaque composant :
|
||||
|
||||
| Composant | Usage | Position dans la landing page |
|
||||
| :--- | :--- | :--- |
|
||||
| `Navbar` | Barre de navigation supérieure | Tout en haut de la page, fixe |
|
||||
| `Button` | Bouton, supporte plusieurs variantes et couleurs | Boutons CTA, boutons de navigation |
|
||||
| `Card` | Conteneur de carte | Présentation des fonctionnalités, cartes de tarifs |
|
||||
| `Chip` | Petite étiquette | Marqueurs « Recommandé », « Le plus populaire » |
|
||||
| `Divider` | Ligne de séparation | Séparation visuelle entre les sections |
|
||||
|
||||
### 3.4 Itération et optimisation
|
||||
|
||||
La première version du code généré peut ne pas être entièrement satisfaisante. Continuez à dialoguer avec l'IA pour ajuster :
|
||||
|
||||
```text
|
||||
Aidez-moi à optimiser la landing page :
|
||||
|
||||
1. Ajoutez un dégradé au grand titre, du bleu au violet
|
||||
2. Les cartes de fonctionnalités doivent avoir un effet de lévitation au survol de la souris
|
||||
3. La carte de prix de la version pro doit être mise en évidence, avec une bordure et une étiquette « Le plus populaire »
|
||||
4. Sur mobile, la navigation doit devenir un menu hamburger (les trois barres horizontales)
|
||||
```
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran de la landing page après itération -->
|
||||
<!--  -->
|
||||
|
||||
> **Le cœur du Vibe Coding** : vous n'avez pas besoin de mémoriser l'API de chaque composant. Il vous suffit de décrire l'effet souhaité en langage naturel, et l'IA trouvera les composants et la syntaxe appropriés. Si le résultat ne vous satisfait pas, continuez à itérer via le dialogue.
|
||||
|
||||
## 4. Pratique 2 : Construire une page produit avec shadcn/ui
|
||||
|
||||
**Scénario** : Votre assistant d'écriture AI a besoin d'une interface principale après connexion — une liste de documents à gauche, un éditeur à droite, et une barre d'outils en haut. C'est une page produit fonctionnelle nécessitant une UI hautement personnalisable.
|
||||
|
||||
**Pourquoi choisir shadcn/ui** : shadcn/ui place le code des composants directement dans votre projet, vous pouvez modifier n'importe quel détail. Pour les interfaces produit nécessitant une personnalisation approfondie, ce modèle « propriété du code » est le plus flexible.
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran du site shadcn/ui ou de la présentation des composants -->
|
||||
<!--  -->
|
||||
|
||||
### 4.1 Créer le projet
|
||||
|
||||
```bash
|
||||
# Créer un projet Next.js
|
||||
npx create-next-app@latest ai-writer-app --typescript --tailwind --app
|
||||
cd ai-writer-app
|
||||
|
||||
# Initialiser shadcn/ui
|
||||
npx shadcn@latest init
|
||||
|
||||
# Ajouter les composants selon les besoins (pas d'installation en bloc)
|
||||
npx shadcn@latest add button card input sidebar sheet dialog
|
||||
```
|
||||
|
||||
La particularité de shadcn/ui : à chaque `add` d'un composant, il copie le code source dans le répertoire `components/ui/` de votre projet. Vous pouvez ouvrir directement ces fichiers pour modifier les styles et le comportement.
|
||||
|
||||
### 4.2 Générer l'interface produit avec l'IDE AI
|
||||
|
||||
```text
|
||||
Aidez-moi à créer l'interface principale d'un assistant d'écriture AI, en utilisant la bibliothèque de composants shadcn/ui :
|
||||
|
||||
**Mise en page globale :**
|
||||
- À gauche, une barre latérale rétractable d'environ 280px :
|
||||
- En haut, un bouton « Nouveau document »
|
||||
- En dessous, une liste de documents, chaque document affichant le titre et la date de dernière modification
|
||||
- Clic droit sur un document pour renommer ou supprimer
|
||||
- À droite, la zone d'édition principale, divisée en deux parties :
|
||||
- En haut, une barre d'outils : édition du titre du document, affichage du compteur de mots, bouton « Continuation AI », menu déroulant « Exporter »
|
||||
- En bas, la zone d'édition : un grand champ de saisie de texte occupant tout l'espace restant
|
||||
|
||||
**Détails d'interaction :**
|
||||
- Après un clic sur « Continuation AI », le bouton affiche un état de chargement, le texte généré par l'IA apparaît en bas de l'éditeur (effet machine à écrire, lettre par lettre)
|
||||
- Sur mobile, la barre latérale devient un tiroir glissant depuis la gauche
|
||||
- Le document actuellement sélectionné doit être mis en évidence
|
||||
```
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran de l'interface produit shadcn/ui générée par l'IA -->
|
||||
<!--  -->
|
||||
|
||||
### 4.3 Composants clés utilisés par l'IA
|
||||
|
||||
```tsx
|
||||
import { Button } from '@/components/ui/button'
|
||||
import { Input } from '@/components/ui/input'
|
||||
import { Card, CardContent, CardHeader } from '@/components/ui/card'
|
||||
import {
|
||||
DropdownMenu,
|
||||
DropdownMenuContent,
|
||||
DropdownMenuItem,
|
||||
DropdownMenuTrigger
|
||||
} from '@/components/ui/dropdown-menu'
|
||||
import {
|
||||
Sheet,
|
||||
SheetContent,
|
||||
SheetTrigger
|
||||
} from '@/components/ui/sheet'
|
||||
import {
|
||||
Sidebar,
|
||||
SidebarContent,
|
||||
SidebarHeader
|
||||
} from '@/components/ui/sidebar'
|
||||
```
|
||||
|
||||
| Composant | Usage | Position dans la page produit |
|
||||
| :--- | :--- | :--- |
|
||||
| `Sidebar` | Barre latérale rétractable | Liste de documents à gauche |
|
||||
| `Sheet` | Tiroir mobile | Remplacement de la barre latérale sur mobile |
|
||||
| `DropdownMenu` | Menu déroulant | Bouton « Exporter », menu contextuel |
|
||||
| `Dialog` | Boîte de dialogue | Confirmation de renommage, suppression |
|
||||
| `Button` | Bouton, supporte variant et loading | Divers boutons d'action |
|
||||
| `Input` | Champ de saisie | Édition du titre du document |
|
||||
|
||||
### 4.4 Personnaliser les styles des composants
|
||||
|
||||
L'avantage de shadcn/ui est que vous pouvez modifier directement le code source des composants. Par exemple, pour des boutons aux coins plus arrondis :
|
||||
|
||||
```text
|
||||
Aidez-moi à modifier components/ui/button.tsx,
|
||||
changez le coin arrondi par défaut de tous les boutons de rounded-md à rounded-xl,
|
||||
et ajoutez un effet d'ombre subtil à la variante primary
|
||||
```
|
||||
|
||||
L'IA modifiera directement les fichiers de composants dans votre projet, au lieu de remplacer les styles du package npm — c'est l'avantage de « posséder le code » avec shadcn/ui.
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran montrant le code source shadcn/ui éditable dans le projet -->
|
||||
<!--  -->
|
||||
|
||||
## 5. Pratique 3 : Construire un back-office avec Ant Design
|
||||
|
||||
**Scénario** : Après le lancement de votre assistant d'écriture AI, vous avez besoin d'un back-office pour consulter les données utilisateurs, gérer le contenu des documents et traiter les commandes payantes. Le cœur d'un système de back-office est la présentation des données et l'efficacité des opérations.
|
||||
|
||||
**Pourquoi choisir Ant Design** : Ant Design a l'expérience la plus profonde dans le domaine des back-offices. Les composants métier comme les tableaux, formulaires et graphiques sont prêts à l'emploi, avec un grand nombre de modèles d'interaction de niveau entreprise intégrés (opérations par lot, filtrage avancé, export de données, etc.).
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran du site Ant Design ou de la présentation des Pro Components -->
|
||||
<!--  -->
|
||||
|
||||
### 5.1 Créer le projet
|
||||
|
||||
```bash
|
||||
# Utiliser le scaffolding Ant Design Pro (mise en page, routage et permissions intégrés)
|
||||
npx create-umi@latest ai-writer-admin
|
||||
# Choisir le template Ant Design Pro
|
||||
cd ai-writer-admin
|
||||
npm install
|
||||
```
|
||||
|
||||
Ou partir de zéro :
|
||||
|
||||
```bash
|
||||
npx create-react-app ai-writer-admin --template typescript
|
||||
cd ai-writer-admin
|
||||
npm install antd @ant-design/icons @ant-design/pro-components
|
||||
```
|
||||
|
||||
### 5.2 Générer le back-office avec l'IDE AI
|
||||
|
||||
```text
|
||||
Aidez-moi à créer un back-office pour un assistant d'écriture AI, en utilisant la bibliothèque de composants Ant Design :
|
||||
|
||||
**Mise en page globale :**
|
||||
- À gauche, la barre de menus : Tableau de bord, Gestion des utilisateurs, Gestion des documents, Gestion des commandes, Paramètres système
|
||||
- En haut, le fil d'Ariane
|
||||
|
||||
**Page de gestion des utilisateurs :**
|
||||
- En haut, quatre cartes statistiques : nombre total d'utilisateurs, nouvelles inscriptions aujourd'hui, utilisateurs actifs, utilisateurs payants
|
||||
- Zone de recherche et filtrage : recherche par nom d'utilisateur, sélection de la plage de date d'inscription, filtrage par statut, avec boutons « Rechercher » et « Réinitialiser »
|
||||
- Tableau des utilisateurs :
|
||||
- Affiche avatar, nom d'utilisateur, email, date d'inscription, plan d'abonnement (étiquettes de couleurs différentes), statut, actions
|
||||
- 20 éléments par page avec pagination
|
||||
- Possibilité de sélection multiple pour désactivation ou export par lot
|
||||
- Colonne d'actions : voir les détails, modifier, désactiver (confirmation requise avant désactivation)
|
||||
- Un clic sur « Voir les détails » ouvre un tiroir latéral avec les informations détaillées et la liste des documents récents
|
||||
```
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran de l'interface back-office Ant Design générée par l'IA -->
|
||||
<!--  -->
|
||||
|
||||
### 5.3 Composants clés utilisés par l'IA
|
||||
|
||||
```tsx
|
||||
import { PageContainer, ProLayout } from '@ant-design/pro-components'
|
||||
import { ProTable } from '@ant-design/pro-components'
|
||||
import { StatisticCard } from '@ant-design/pro-components'
|
||||
import {
|
||||
Button, Tag, Badge, Space, Drawer,
|
||||
Popconfirm, message, Modal
|
||||
} from 'antd'
|
||||
import {
|
||||
UserOutlined, SearchOutlined, ExportOutlined
|
||||
} from '@ant-design/icons'
|
||||
```
|
||||
|
||||
| Composant | Usage | Position dans le back-office |
|
||||
| :--- | :--- | :--- |
|
||||
| `ProLayout` | Framework de mise en page global du back-office | Squelette de la page (menu + zone de contenu) |
|
||||
| `ProTable` | Tableau avancé avec recherche, pagination et paramètres de colonnes intégrés | Liste des utilisateurs, liste des documents, liste des commandes |
|
||||
| `StatisticCard` | Carte de statistiques | Tableau de bord, aperçu en haut de page |
|
||||
| `Tag` / `Badge` | Étiquettes de statut | Plans d'abonnement, statut utilisateur |
|
||||
| `Drawer` | Tiroir latéral | Détails utilisateur, formulaire d'édition |
|
||||
| `Popconfirm` | Confirmation en bulle | Actions dangereuses comme suppression, désactivation |
|
||||
|
||||
### 5.4 Continuer l'itération : Ajouter le tableau de bord
|
||||
|
||||
```text
|
||||
Aidez-moi à créer une page de tableau de bord :
|
||||
|
||||
1. En haut, quatre cartes statistiques : nombre total d'utilisateurs, nombre total de documents, appels API aujourd'hui, revenus mensuels, chaque carte affichant la valeur et la variation (hausse ou baisse)
|
||||
2. Au milieu, deux graphiques :
|
||||
- À gauche : graphique en courbes de la croissance des utilisateurs sur 7 jours
|
||||
- À droite : graphique en secteurs de la répartition des plans d'abonnement
|
||||
3. En bas : tableau du journal des opérations récentes, affichant l'heure, l'utilisateur, le type d'opération et les détails
|
||||
|
||||
Utilisez les composants Ant Design pour la mise en page, les graphiques peuvent utiliser Ant Design Charts
|
||||
```
|
||||
|
||||
<!-- TODO: Remplacer par une capture d'écran de la page du tableau de bord -->
|
||||
<!--  -->
|
||||
|
||||
> **Astuce Vibe Coding pour le back-office** : La structure des pages de back-office est relativement fixe (tableau + recherche + modale), parfaitement adaptée à la génération par lot avec l'IA. Vous pouvez d'abord faire générer une page « Gestion des utilisateurs » comme template, puis dire « En vous référant à la structure de la page de gestion des utilisateurs, aidez-moi à générer la page de gestion des documents » — l'IA réutilisera le même modèle de mise en page.
|
||||
|
||||
## 6. Apprendre à consulter la documentation : le « mode d'emploi » des bibliothèques de composants
|
||||
|
||||
En Vibe Coding, l'IA écrira la plupart du code pour vous. Mais quand le résultat généré par l'IA n'est pas correct, ou que vous voulez ajuster le comportement d'un composant, **consulter la documentation** est la solution la plus rapide.
|
||||
|
||||
Prenons Ant Design comme exemple. L'adresse de sa documentation est : `https://ant.design/components/overview-cn`
|
||||
|
||||
Le processus standard pour consulter la documentation :
|
||||
|
||||
1. **Clarifier le besoin** : par exemple « J'ai besoin que le tableau supporte la sélection de lignes »
|
||||
2. **Rechercher dans la documentation** : chercher « Table » pour accéder à la page du composant tableau
|
||||
3. **Consulter les exemples** : chaque composant a plusieurs exemples en ligne dans la documentation, trouvez l'exemple « sélectionnable »
|
||||
4. **Copier le code** : copiez le code de l'exemple dans votre projet
|
||||
5. **Consulter le tableau API** : trouvez la configuration complète de la propriété `rowSelection` en bas de page
|
||||
|
||||
> Vous pouvez aussi envoyer directement le lien de la documentation à l'IDE AI : « Veuillez vous référer à l'API rowSelection de https://ant.design/components/table-cn pour ajouter la fonctionnalité de sélection multiple au tableau des utilisateurs ». Fournir le lien de la documentation à l'IA rendra le code généré plus précis.
|
||||
|
||||
Tableau de référence rapide des adresses de documentation des bibliothèques :
|
||||
|
||||
| Bibliothèque | Adresse de la documentation |
|
||||
| :--- | :--- |
|
||||
| Ant Design | `https://ant.design/components/overview-cn` |
|
||||
| shadcn/ui | `https://ui.shadcn.com/docs/components` |
|
||||
| HeroUI | `https://heroui.com/docs/components` |
|
||||
| Material UI | `https://mui.com/material-ui/all-components/` |
|
||||
| Element Plus | `https://element-plus.org/zh-CN/component/overview.html` |
|
||||
|
||||
## 7. Résumé
|
||||
|
||||
Les trois scénarios pratiques couvrent les besoins de développement frontend les plus courants :
|
||||
|
||||
| Scénario | Bibliothèque recommandée | Caractéristique principale |
|
||||
| :--- | :--- | :--- |
|
||||
| Landing page / Page vitrine | HeroUI | Styles par défaut élégants, animations fluides, fort impact visuel |
|
||||
| Page produit fonctionnelle | shadcn/ui | Code entièrement contrôlable, personnalisation approfondie flexible |
|
||||
| Système de back-office | Ant Design | Composants métier riches, tableaux et formulaires prêts à l'emploi |
|
||||
|
||||
Résumé du workflow Vibe Coding :
|
||||
|
||||
1. Choisir la bibliothèque de composants appropriée selon le scénario
|
||||
2. Décrire la structure de page et les interactions souhaitées avec l'IDE AI
|
||||
3. L'IA génère le code initial, vous prévisualisez le résultat
|
||||
4. Continuer à itérer et ajuster en langage naturel
|
||||
5. En cas de problème de détail, consulter la documentation de la bibliothèque de composants
|
||||
|
||||
### Exercices
|
||||
|
||||
Choisissez l'un des scénarios suivants et réalisez-le de zéro avec IDE AI + bibliothèque de composants :
|
||||
|
||||
1. Avec HeroUI, créez une landing page vitrine pour un projet précédent (comme les Portraits de Poudlard)
|
||||
2. Avec shadcn/ui, construisez l'interface principale d'une application de notes (barre latérale + éditeur)
|
||||
3. Avec Ant Design, construisez un simple back-office de gestion de contenu (liste d'articles + formulaire de création)
|
||||
|
||||
---
|
||||
|
||||
## Annexe : Aperçu de plus de bibliothèques de composants
|
||||
|
||||
Outre les quatre bibliothèques clés présentées dans le corps du texte, l'écosystème frontend propose de nombreuses autres excellentes bibliothèques. Voici une liste classée par framework pour faciliter votre choix en fonction des besoins du projet.
|
||||
|
||||
### Écosystème Vue
|
||||
|
||||
| Bibliothèque | Stars | Description | Scénarios d'utilisation |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [Element Plus](https://element-plus.org) | ~27k | Bibliothèque de composants enterprise Vue 3 créée par l'équipe Ele.me, la plus utilisée en Chine, excellente documentation en chinois | Back-offices et systèmes de gestion |
|
||||
| [Vuetify](https://vuetifyjs.com) | ~41k | Bibliothèque de composants Material Design pour Vue la plus populaire, 80+ composants, documentation complète | Projets au style Google Design |
|
||||
| [Ant Design Vue](https://antdv.com) | ~21k | Bibliothèque de composants Vue 3 basée sur le système de design d'Ant, spécifications de design unifiées | Back-offices enterprise |
|
||||
| [Naive UI](https://www.naiveui.com) | ~18k | Écrite en TypeScript, personnalisation de thème extrêmement flexible, sans dépendance à un préprocesseur CSS | Projets avec exigences de design uniques |
|
||||
| [Quasar](https://quasar.dev) | ~27k | Un seul code pour construire des applications SPA, SSR, PWA, mobiles et desktop | Projets multi-plateformes |
|
||||
| [Vant](https://vant-ui.github.io/vant) | ~24k | Bibliothèque de composants mobiles légère développée par l'équipe Youzan, couvrant les besoins courants du e-commerce | Pages H5 mobiles |
|
||||
| [PrimeVue](https://primevue.org) | ~14k | 90+ composants, support de plusieurs thèmes (Material, Bootstrap, etc.) | Besoin de composants riches et multi-thèmes |
|
||||
| [Arco Design Vue](https://arco.design/vue) | ~3k | Produit par ByteDance, haute qualité de composants, mode sombre intégré | Produits de back-office |
|
||||
| [TDesign Vue Next](https://tdesign.tencent.com/vue-next) | ~2k | Produit par Tencent, langage de design unifié, couvrant les scénarios desktop courants | Écosystème Tencent ou projets enterprise |
|
||||
|
||||
### Écosystème React
|
||||
|
||||
| Bibliothèque | Stars | Description | Scénarios d'utilisation |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [Material UI (MUI)](https://mui.com) | ~95k | Implémentation historique des guidelines Material Design de Google, composants les plus complets, écosystème le plus mature | Construction rapide d'applications enterprise |
|
||||
| [Ant Design](https://ant.design) | ~94k | Produit par Ant Group, intègre de nombreux composants métier de haute qualité, position dominante dans la communauté des développeurs chinois | Back-offices enterprise |
|
||||
| [shadcn/ui](https://ui.shadcn.com) | ~83k | Le code est copié dans le projet plutôt qu'installé via npm, basé sur Radix UI + Tailwind CSS, entièrement contrôlable | Projets nécessitant une personnalisation approfondie |
|
||||
| [Chakra UI](https://chakra-ui.com) | ~39k | Centrée sur l'expérience développeur, API simple, support d'accessibilité intégré | Prototypage rapide |
|
||||
| [Mantine](https://mantine.dev) | ~28k | 100+ composants et 50+ hooks, incluant sélecteur de dates, éditeur de texte riche et autres composants avancés | Solution complète prête à l'emploi |
|
||||
| [Headless UI](https://headlessui.com) | ~27k | Bibliothèque de composants sans style officielle de Tailwind Labs, supporte React et Vue | À utiliser avec Tailwind CSS |
|
||||
| [HeroUI](https://heroui.com) | ~24k | Basée sur Tailwind CSS + React Aria, styles par défaut élégants, animations fluides | Projets exigeants visuellement |
|
||||
| [Radix UI](https://www.radix-ui.com) | ~17k | Bibliothèque de primitives de composants sans style, axée sur l'accessibilité et le comportement, base de shadcn/ui | Construire un système de design personnalisé |
|
||||
|
||||
#### Écosystème d'extensions shadcn/ui
|
||||
|
||||
Outre les bibliothèques de composants génériques ci-dessus, l'écosystème shadcn/ui a vu apparaître de nombreuses bibliothèques d'extensions basées sur sa philosophie, offrant des choix différenciés pour des scénarios spécifiques. Ces extensions adoptent également le modèle « copier le code dans le projet », donnant aux développeurs un contrôle total du code source.
|
||||
|
||||
| Bibliothèque | Description | Scénarios d'utilisation |
|
||||
| :--- | :--- | :--- |
|
||||
| [Aceternity UI](https://ui.aceternity.com) | 200+ composants de qualité production, spécialisée dans les cartes lumineuses, dégradés de texte, globe 3D et autres composants visuels distinctifs | Landing pages de haute qualité, produits SaaS |
|
||||
| [Tailark UI](https://tailark.com) | Collection de blocs de composants pour sites marketing, modules fréquents comme présentation produit, témoignages, boutons CTA | Landing pages marketing, sites produit |
|
||||
| [UI Tripled](https://ui.tripled.work) | Composants d'interaction dynamique basés sur Framer Motion, modales, navigation, animations de cartes | Outils créatifs, portfolios personnels |
|
||||
| [Neobrutalism UI](https://neobrutalism.dev) | Style néobrutaliste, lignes épaisses, contraste élevé, couleurs vives | Sites de marque personnalisés, projets créatifs |
|
||||
| [REUI](https://reui.io) | 967+ modèles de combinaisons de composants pour scénarios métier réels | Back-offices enterprise, formulaires complexes |
|
||||
| [Cult UI](https://cult-ui.com) | Finition interaction/visuelle plus poussée, tableaux de données, panneaux de filtrage et autres composants composites | Projets commerciaux de haute qualité |
|
||||
| [Kibo UI](https://kibo-ui.com) | Composants métier avancés, sélecteur de couleurs, éditeur de texte riche, upload de fichiers | Back-offices, produits de type outils |
|
||||
| [Kokonut UI](https://kokonutui.com) | 100+ composants + 7+ templates complets, style frais et minimaliste | Sites SaaS, blogs, e-commerce |
|
||||
| [Commerce UI](https://ui.stackzero.co) | Spécialisée e-commerce, cartes produit, panier, formulaire de commande | Plateformes e-commerce |
|
||||
| [shadcnblocks](https://shadcnblocks.com) | 1373 blocs UI + 13 templates complets, les ressources les plus complètes | Tous les scénarios |
|
||||
| [Shoogle](https://shoogle.dev) | Plateforme d'agrégation et de recherche de l'écosystème shadcn/ui | Recherche rapide de ressources |
|
||||
| [Discover All Shadcn](https://allshadcn.com) | Navigation agrégée de ressources | Recherche rapide de ressources |
|
||||
|
||||
> **Pourquoi choisir les extensions shadcn/ui ?** Ces extensions héritent de la philosophie de « propriété du code » de shadcn/ui tout en offrant une personnalisation approfondie pour des scénarios spécifiques. À l'ère du Vibe Coding, elles vous permettent de trouver rapidement des composants correspondant à vos besoins de design, de sortir de l'homogénéisation des bibliothèques UI mainstream et de créer des produits plus différenciés.
|
||||
@@ -0,0 +1,425 @@
|
||||
# Concevoir des pages et des boutons en référençant les guidelines UI
|
||||
|
||||
Beaucoup de gens disent « Je voudrais que ma page ressemble davantage à Apple » ou « J'aimerais des boutons plus sophistiqués », mais quand il s'agit de passer à l'action, ils se heurtent souvent à une question :
|
||||
|
||||
**Que faut-il référencer exactement ?**
|
||||
|
||||
Copier des captures d'écran ne vous apprend qu'à « ressembler ou non ». Mais en ouvrant les guidelines de design d'Apple, Google, Microsoft et Atlassian, vous découvrirez que leur véritable force n'est pas le style visuel, mais la **manière dont ils expliquent clairement les problèmes de design** : ce qu'une page doit mettre en avant, comment hiérarchiser les boutons, comment mettre en évidence les actions — ces critères de jugement sont le cœur du sujet.
|
||||
|
||||
> Référencer les guidelines de design n'a pas pour but de « ressembler à quelqu'un », mais d'apprendre comment les autres prennent des décisions.
|
||||
|
||||
:::: info Pourquoi apprendre cela aujourd'hui encore
|
||||
Les règles de design ont déjà été intégrées dans les modèles par l'entraînement, absorbées par défaut dans les outils de conception, et même assimilées par l'IA à partir de quelques captures d'écran. Mais il reste nécessaire de savoir d'où viennent ces règles et pourquoi elles sont ainsi définies.
|
||||
::::
|
||||
|
||||
## Quelques citations originales pour mesurer l'écart
|
||||
|
||||
Si vous pensiez que « les guidelines de design, c'est juste parler de style », lisez d'abord quelques citations officielles.
|
||||
|
||||
Dans une équipe, on entend souvent dire des choses comme :
|
||||
|
||||
- Fais un menu déroulant
|
||||
- Mets un menu ici
|
||||
- Ajoute quelques fonctionnalités dans la barre de menus
|
||||
- Mets deux boutons ici, un pour confirmer et un pour annuler
|
||||
|
||||
Cela semble correct, mais dans les guidelines des grandes entreprises, ces termes ne sont pas des concepts flous — ils sont décomposés de manière très précise.
|
||||
|
||||
| Ce qu'on dit couramment | Citation officielle | En résumé |
|
||||
| :--- | :--- | :--- |
|
||||
| « Fais un menu » | Apple : [« A menu reveals its options... »](https://developer.apple.com/design/human-interface-guidelines/menus) | `Menu` sert à effectuer des actions |
|
||||
| « Mets des fonctionnalités dans la barre de menus » | Apple : [« menu bar menus contain all the commands... »](https://developer.apple.com/design/human-interface-guidelines/menus) | C'est le menu de commandes de l'application en haut |
|
||||
| « Fais un menu déroulant » | Apple : [« A pop-up list lets the user choose one option among several. »](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/ManagingPopUpItems.html) | `pop-up` sert à choisir une option dans une liste |
|
||||
| « Fais aussi un menu déroulant » | Apple : [« A pull-down list is generally used for selecting commands in a specific context. »](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/ManagingPopUpItems.html) | `pull-down` sert à déclencher des commandes dans le contexte actuel |
|
||||
| « Un menu peut aussi servir à filtrer » | Fluent : [« If you need to collect information from people, try a select, dropdown, or combobox instead. »](https://fluent2.microsoft.design/components/web/react/core/menu/usage) | `Menu` ne sert pas à sélectionner des valeurs |
|
||||
| « Un menu peut servir de navigation » | Material : [« Menus should not be used as a primary method for navigation within an app. »](https://m1.material.io/components/menus.html) | `Menu` n'est pas une navigation principale |
|
||||
| « Mets juste OK / Annuler sur les boutons » | Apple : [« Always use 'Cancel' to title a button that cancels the alert's action. »](https://developer.apple.com/design/human-interface-guidelines/alerts) | Le texte des boutons ne s'écrit pas au hasard |
|
||||
|
||||
> Les citations du tableau sont toutes cliquables et renvoient vers les pages officielles correspondantes.
|
||||
|
||||
C'est la chose qui frappe le plus quand on lit vraiment des guidelines de design pour la première fois :
|
||||
|
||||
> Quand nous pensons discuter d'UI, la plupart du temps nous ne faisons que communiquer avec un tas de termes vagues.
|
||||
|
||||
Apple ne dit pas simplement « fais un menu » ; elle continue à distinguer :
|
||||
|
||||
- `menu`
|
||||
- `menu bar menu`
|
||||
- `pop-up button`
|
||||
- `pull-down button`
|
||||
- `context menu`
|
||||
|
||||
Fluent ne dit pas simplement « menu déroulant » ; elle continue à distinguer :
|
||||
|
||||
- `menu`
|
||||
- `dropdown`
|
||||
- `select`
|
||||
- `combobox`
|
||||
|
||||
C'est ça, la nécessité des guidelines de design.
|
||||
|
||||
Ce n'est pas pour rendre les pages plus professionnelles, mais pour que l'équipe, lorsqu'elle discute d'UI, n'ait plus chacun une idée différente en tête.
|
||||
|
||||
## Ce que vous allez apprendre
|
||||
|
||||
1. Pourquoi il faut consulter les guidelines de design avant de concevoir des pages et des boutons
|
||||
2. Quels contenus des guidelines d'Apple, Material, Fluent et Atlassian méritent le plus d'attention
|
||||
3. Comment concevoir clairement la « hiérarchie des pages » et la « hiérarchie des boutons »
|
||||
4. Comment faire en sorte que l'IA référence les guidelines des autres pour générer des pages et des boutons
|
||||
|
||||
## 1. Pourquoi les guidelines de design vous aident à clarifier les pages
|
||||
|
||||
Après avoir lu les citations ci-dessus, vous remarquerez un point essentiel :
|
||||
|
||||
**Les guidelines de design ne sont pas la cerise sur le gâteau, elles servent d'abord à employer les bons termes.**
|
||||
|
||||
Beaucoup de pages ne sont pas belles non pas parce que les couleurs ne sont pas assez sophistiquées, mais parce que la hiérarchie de l'information est chaotique.
|
||||
|
||||
Beaucoup de boutons ne sont pas pratiques non pas parce que les coins arrondis sont mal choisis, mais parce que :
|
||||
|
||||
- Il y a trop de boutons principaux, l'utilisateur ne sait pas lequel cliquer
|
||||
- Les boutons dangereux et les boutons normaux se ressemblent
|
||||
- Tous les boutons de la page se disputent l'attention
|
||||
- Les styles et la sémantique des boutons sont incohérents d'une page à l'autre
|
||||
|
||||
Les guidelines de design matures résolvent précisément ces problèmes. Elles définissent généralement :
|
||||
|
||||
| Contenu de la guideline | Quel problème elle résout |
|
||||
| :--- | :--- |
|
||||
| **Hiérarchie des pages** | Que regarder en premier, ensuite, comment organiser l'information |
|
||||
| **Fondements visuels** | Couleurs, espacements, typographie, coins arrondis, ombres — comment uniformiser |
|
||||
| **Hiérarchie des boutons** | Comment distinguer les boutons principaux, secondaires, textuels et dangereux |
|
||||
| **Règles d'états** | Comment afficher hover, focus, disabled, loading |
|
||||
| **Sémantique d'interaction** | Quel bouton est « confirmer », lequel est « annuler », lequel est « plus d'actions » |
|
||||
|
||||
Ainsi, ce que les guidelines de design fournissent véritablement, ce n'est pas un « habillage », mais un ensemble de **critères de jugement**.
|
||||
|
||||
## 2. Que regarder en priorité dans les guidelines des grandes entreprises
|
||||
|
||||
### 2.1 Référencer Apple : apprendre à « définir les choses assez finement »
|
||||
|
||||
Ce qu'il y a de plus précieux chez Apple, ce n'est pas seulement la retenue visuelle, mais le fait qu'elle définit les concepts de manière très précise.
|
||||
|
||||
Pour ce que beaucoup d'équilles appellent « menu » ou « menu déroulant », Apple va encore plus loin :
|
||||
|
||||
- `menu` : un ensemble de commandes, d'options ou d'états
|
||||
- `menu bar menu` : collection de commandes au niveau de l'application
|
||||
- `pop-up button` : choisir une valeur
|
||||
- `pull-down button` : déclencher une commande dans le contexte actuel
|
||||
- `context menu` : actions courantes liées à l'objet ou à la tâche en cours
|
||||
|
||||
Cette distinction est très importante, car elle affecte directement :
|
||||
|
||||
- Ce composant sert-il à choisir une valeur ou à effectuer une action
|
||||
- Appartient-il à une partie de la page ou au niveau de l'application
|
||||
- Doit-il afficher en permanence la valeur sélectionnée ou s'ouvrir temporairement pour des commandes
|
||||
|
||||
Quand vous commencez à penser à ce niveau de granularité, vos pages deviennent immédiatement beaucoup plus claires.
|
||||
|
||||
### 2.2 Référencer Apple : apprendre la hiérarchie des pages et la retenue
|
||||
|
||||
Les Apple Human Interface Guidelines sont particulièrement adaptées pour apprendre deux choses :
|
||||
|
||||
- Comment établir une hiérarchie claire dans une page
|
||||
- Comment les contrôles restent explicites sans voler la vedette
|
||||
|
||||
Apple met l'accent sur `Hierarchy`, `Harmony`, `Consistency`. Cela signifie que la conception de la page doit répondre à :
|
||||
|
||||
- Quelle est l'information la plus importante de la page actuelle
|
||||
- Quelle est la tâche principale de l'utilisateur
|
||||
- Quelle action doit être la plus visible, et quelle action doit s'effacer
|
||||
|
||||
Si vous référencez Apple pour concevoir des pages, vous pouvez vous inspirer de :
|
||||
|
||||
- Ne pas trop fragmenter l'information au-dessus de la ligne de flottaison, concentrez-vous d'abord sur le contenu essentiel
|
||||
- Utiliser l'espace blanc, la taille de police et le regroupement pour établir l'ordre, plutôt qu'empiler des bordures
|
||||
- Ne pas mettre tous les boutons en forte emphase, seules les actions clés doivent être les plus visibles
|
||||
|
||||
### 2.3 Référencer Material : apprendre une structure de page claire
|
||||
|
||||
Material Design est très adapté pour apprendre « comment une page organise les flux de tâches ».
|
||||
|
||||
Beaucoup de ses composants et spécifications de mise en page ont pour cœur de vous aider à clarifier :
|
||||
|
||||
- La page est-elle de type navigation ou exécution de tâche
|
||||
- La page actuelle demande-t-elle à l'utilisateur de lire, de choisir ou de soumettre
|
||||
- Dans une page, quels éléments doivent être stables et répétés, et quels éléments doivent répondre aux changements de contexte
|
||||
|
||||
Si vous référencez Material pour concevoir des pages, vous pouvez vous inspirer de :
|
||||
|
||||
- Des blocs de page clairs, avec des responsabilités de modules bien définies
|
||||
- Une répartition claire entre navigation, zone de contenu et zone d'actions
|
||||
- Des styles de boutons différents correspondant à des priorités d'action différentes
|
||||
|
||||
### 2.4 Référencer Fluent : apprendre les frontières des composants et la hiérarchie des boutons
|
||||
|
||||
Fluent 2 est très adapté aux back-offices, aux produits de type outils et aux systèmes de formulaires complexes. Son point le plus précieux est qu'il vous dit directement « ne mélangez pas les concepts ».
|
||||
|
||||
Par exemple, il indique clairement : si vous devez « collect information », n'utilisez plus `menu`, mais envisagez plutôt `select`, `dropdown`, `combobox`.
|
||||
|
||||
Cette phrase est très importante, car elle brise l'idée que beaucoup de gens se font que « c'est à peu près pareil ».
|
||||
|
||||
Fluent 2 attache aussi beaucoup d'importance à :
|
||||
|
||||
- La hiérarchie des actions
|
||||
- Les frontières sémantiques des composants
|
||||
- La clarté dans les scénarios d'information dense
|
||||
|
||||
Si vous référencez Fluent pour concevoir des boutons, vous pouvez vous inspirer de :
|
||||
|
||||
- `Primary button` pour l'action la plus importante de la zone
|
||||
- `Secondary button` pour les actions de support
|
||||
- Les boutons à faible emphase comme `Subtle`, `Transparent` pour les actions qui ne doivent pas perturber le flux principal
|
||||
- Plus il y a de boutons dans une page, plus il faut contrôler la priorité visuelle
|
||||
|
||||
### 2.5 Référencer Atlassian : apprendre à gérer systématiquement les pages et les boutons
|
||||
|
||||
L'Atlassian Design System est particulièrement adapté quand « une équipe travaille sur beaucoup de pages ». Il met l'accent sur :
|
||||
|
||||
- Les foundations comme base partagée
|
||||
- Les tokens comme méthode d'unification des décisions visuelles
|
||||
- Les components comme éléments d'interaction réutilisables
|
||||
|
||||
Si vous référencez Atlassian pour les pages et les boutons, le plus précieux est :
|
||||
|
||||
- Faire des règles uniformes pour la taille, la couleur, les coins arrondis et l'espacement des boutons
|
||||
- Fixer le rythme de la mise en page
|
||||
- Faire en sorte que des pages différentes, au contenu différent, partagent le même langage structurel
|
||||
|
||||
## 3. Quand vous concevez des pages, quels points des guidelines devez-vous consulter
|
||||
|
||||
Quand vous consultez un système de design, ne demandez pas d'abord « cette page est-elle jolie », mais posez d'abord les questions suivantes.
|
||||
|
||||
### 3.1 Au premier coup d'œil, la priorité est-elle claire
|
||||
|
||||
Une page comporte généralement au moins trois niveaux :
|
||||
|
||||
- **Information principale** : le contenu le plus important de la page actuelle
|
||||
- **Information secondaire** : contenu aidant à comprendre ou à compléter
|
||||
- **Actions secondaires** : actions qui ne doivent pas perturber la tâche principale
|
||||
|
||||
Si les trois niveaux ne sont pas séparés, la page sera « tout est important », ce qui équivaut à « rien n'est important ».
|
||||
|
||||
### 3.2 La mise en page sert-elle la tâche plutôt qu'elle n'empile des modules
|
||||
|
||||
En consultant les guidelines, prêtez attention à :
|
||||
|
||||
- La zone de titre indique-t-elle clairement l'objectif de la page
|
||||
- La zone de contenu principal est-elle organisée autour de la tâche
|
||||
- Les boutons d'action sont-ils proches du contenu associé
|
||||
- L'information secondaire est-elle atténuée
|
||||
|
||||
### 3.3 Les actions dans la page ont-elles une priorité
|
||||
|
||||
Beaucoup de pages montrent 6 boutons d'un coup, et chacun ressemble à un CTA — c'est typique d'une hiérarchie hors de contrôle.
|
||||
|
||||
Une approche plus raisonnable :
|
||||
|
||||
- Une zone ne comporte généralement qu'une seule action principale
|
||||
- Les actions secondaires peuvent utiliser des styles à bordure, textuels ou plus discrets
|
||||
- Les actions à risque ne doivent pas ressembler à l'action principale
|
||||
|
||||
## 4. Quand vous concevez des boutons, quels points des guidelines devez-vous consulter
|
||||
|
||||
Les boutons sont la partie la plus susceptible d'être « conçue à la va-vite », mais aussi celle qui révèle le mieux la maturité d'un système.
|
||||
|
||||
### 4.1 D'abord la « sémantique » des boutons, puis le style
|
||||
|
||||
Ne pensez pas d'abord « bouton bleu ou bouton noir », demandez-vous d'abord quel est le rôle de ce bouton.
|
||||
|
||||
Les rôles courants des boutons peuvent être classés ainsi :
|
||||
|
||||
| Type de bouton | Rôle | Stratégie de style courante |
|
||||
| :--- | :--- | :--- |
|
||||
| **Primary** | L'action la plus critique de la zone | Plein, contraste élevé, le plus visible |
|
||||
| **Secondary** | Action de support | Bordure ou emphase d'un niveau inférieur |
|
||||
| **Tertiary / Text** | Action faible | Texte ou faible présence visuelle |
|
||||
| **Destructive** | Suppression, désactivation, vidage et autres actions à risque | Couleur d'avertissement ou style de risque explicite |
|
||||
| **Icon button** | Action outil locale | Simple, proche du contexte |
|
||||
|
||||
### 4.2 Pas trop de boutons Primary dans une page
|
||||
|
||||
C'est le piège le plus courant pour les débutants.
|
||||
|
||||
S'il y a 4 boutons principaux sur la page, cela revient à n'avoir aucun bouton principal. Le sens d'un bouton principal est précisément de « dire à l'utilisateur ce qu'il doit faire maintenant ».
|
||||
|
||||
Vous pouvez vous inspirer de la pratique commune de nombreux systèmes de design :
|
||||
|
||||
- Une zone principale ne conserve généralement qu'un seul bouton principal
|
||||
- Annuler, retourner, fermer ne doivent généralement pas être au même niveau que le bouton de confirmation
|
||||
- Les actions supplémentaires sont placées dans des boutons secondaires ou des menus
|
||||
|
||||
### 4.3 Les boutons doivent pouvoir exprimer les changements d'état
|
||||
|
||||
Les guidelines définissent généralement les états des boutons de manière très précise :
|
||||
|
||||
- État par défaut
|
||||
- État de survol
|
||||
- État de focus
|
||||
- État désactivé
|
||||
- État de chargement
|
||||
- État de danger
|
||||
|
||||
C'est important, car un bouton n'est pas une image statique, mais l'un des contrôles les plus fréquemment activés par l'utilisateur.
|
||||
|
||||
### 4.4 Le texte des boutons fait aussi partie du design
|
||||
|
||||
Le texte des boutons n'est pas qu'une « question de rédaction », il influence directement la compréhension de l'utilisateur.
|
||||
|
||||
Par exemple :
|
||||
|
||||
- `Enregistrer`
|
||||
- `Enregistrer les modifications`
|
||||
- `Publier maintenant`
|
||||
- `Supprimer le projet`
|
||||
- `Déplacer vers la corbeille`
|
||||
|
||||
Ces textes transmettent des attentes psychologiques très différentes. Les guidelines matures exigent généralement que les labels des boutons expriment clairement l'action, et non utilisent des termes vagues.
|
||||
|
||||
## 5. Une checklist très pratique pour la conception de pages et de boutons
|
||||
|
||||
Quand vous concevez une page vous-même, vous pouvez passer rapidement en revue cette checklist :
|
||||
|
||||
### Checklist page
|
||||
|
||||
- Le titre de la page indique-t-il clairement la tâche en cours
|
||||
- L'information la plus importante au-dessus de la ligne de flottaison est-elle visible d'un coup d'œil
|
||||
- La page est-elle organisée selon le flux de tâches, et non selon ce qui vous vient à l'esprit
|
||||
- Une seule zone ne comporte-t-elle qu'une seule action principale
|
||||
- Le contenu secondaire est-il atténué de manière appropriée
|
||||
|
||||
### Checklist boutons
|
||||
|
||||
- Ce bouton est-il une action principale ou secondaire
|
||||
- Pourquoi mérite-t-il d'être plus visible que les autres
|
||||
- Y a-t-il trop de boutons principaux dans la page
|
||||
- Les actions dangereuses sont-elles clairement identifiées
|
||||
- Le texte du bouton est-il suffisamment précis
|
||||
|
||||
## 6. Comment utiliser l'IA en référençant les guidelines des autres pour concevoir des pages
|
||||
|
||||
Cette section est la plus pratique.
|
||||
|
||||
Beaucoup de gens, quand ils demandent à l'IA de concevoir une page, se contentent de dire :
|
||||
|
||||
```md
|
||||
Aidez-moi à faire une page de paramètres, un peu plus sophistiquée, style Apple
|
||||
```
|
||||
|
||||
Ce type de prompt est trop vague, et l'IA ne peut généralement imiter que « fond blanc, coins arrondis, ombres ».
|
||||
|
||||
Pour les débutants, l'approche la plus pratique n'est pas de résumer vous-même un long texte, mais de coller directement à l'IA les **phrases clés du texte officiel des guidelines**.
|
||||
|
||||
Cette approche a deux avantages :
|
||||
|
||||
- Vous n'avez pas besoin de « traduire » vous-même la pensée de design
|
||||
- L'IA comprend plus facilement la page et les boutons selon les définitions officielles
|
||||
|
||||
### 6.1 Exemple 1 : Faire concevoir par l'IA une page de paramètres en référençant Apple
|
||||
|
||||
Trouvez d'abord une citation d'Apple :
|
||||
|
||||
> [« Establish a clear visual hierarchy... »](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
|
||||
Vous pouvez coller directement ceci à l'IA :
|
||||
|
||||
```md
|
||||
Référencez cette phrase des Apple Human Interface Guidelines :
|
||||
"Establish a clear visual hierarchy..."
|
||||
|
||||
Aidez-moi à concevoir une page de paramètres de sécurité du compte.
|
||||
La hiérarchie de la page doit être claire, les informations importantes en premier, les groupes bien ordonnés.
|
||||
```
|
||||
|
||||
Le point clé de cette rédaction : vous n'avez pas besoin d'expliquer trop de choses vous-même, collez simplement les propres mots d'Apple.
|
||||
|
||||
### 6.2 Exemple 2 : Faire concevoir par l'IA les boutons d'un back-office en référençant Fluent
|
||||
|
||||
Trouvez d'abord une citation de Fluent :
|
||||
|
||||
> [« Only use one primary button in a layout... »](https://fluent2.microsoft.design/components/web/react/core/button/usage)
|
||||
|
||||
Vous pouvez coller directement ceci à l'IA :
|
||||
|
||||
```md
|
||||
Référencez cette phrase de Fluent 2 :
|
||||
"Only use one primary button in a layout..."
|
||||
|
||||
Aidez-moi à concevoir les boutons d'un back-office de gestion d'équipe.
|
||||
Le bouton d'ajout de membre doit être le plus visible, les boutons d'export, de filtrage et d'actions supplémentaires plus discrets, le bouton de suppression mis en évidence séparément.
|
||||
```
|
||||
|
||||
Cette phrase est particulièrement adaptée aux débutants, car elle dit directement à l'IA : ne pas mettre trop de boutons principaux dans une zone.
|
||||
|
||||
### 6.3 Exemple 3 : Faire concevoir par l'IA en référençant simultanément les guidelines de page et de boutons
|
||||
|
||||
Vous pouvez aussi coller deux citations à la fois, pour que l'IA référence à la fois la page et les boutons :
|
||||
|
||||
> Apple : [« Establish a clear visual hierarchy... »](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
>
|
||||
> Fluent : [« Only use one primary button in a layout... »](https://fluent2.microsoft.design/components/web/react/core/button/usage)
|
||||
|
||||
Puis écrivez directement :
|
||||
|
||||
```md
|
||||
Référencez les deux phrases de guidelines de design suivantes :
|
||||
Apple : "Establish a clear visual hierarchy..."
|
||||
Fluent : "Only use one primary button in a layout..."
|
||||
|
||||
Aidez-moi à concevoir une page de détail de projet.
|
||||
La page contient la présentation du projet, les membres, l'activité récente et l'accès aux paramètres.
|
||||
La hiérarchie de la page doit être claire, ne conserver qu'un seul bouton principal, les autres boutons plus discrets.
|
||||
```
|
||||
|
||||
Cette approche est particulièrement adaptée aux débutants, car il vous suffit de savoir copier le texte officiel et d'ajouter deux phrases sur vos besoins.
|
||||
|
||||
## 7. Comment utiliser l'IA en référençant les guidelines de boutons pour générer directement des boutons
|
||||
|
||||
Si vous voulez d'abord faire des boutons, vous pouvez aussi coller directement le texte officiel des guidelines de boutons.
|
||||
|
||||
Par exemple, la définition du bouton par Atlassian est très courte :
|
||||
|
||||
> [« A button triggers an event or action. »](https://atlassian.design/components/button/)
|
||||
|
||||
Vous pouvez demander ceci à l'IA :
|
||||
|
||||
```md
|
||||
Référencez cette phrase d'Atlassian :
|
||||
"A button triggers an event or action."
|
||||
|
||||
Aidez-moi à concevoir un ensemble de styles de boutons pour un back-office.
|
||||
Je veux un bouton principal, un bouton secondaire, un bouton de suppression, et dites-moi respectivement où les utiliser.
|
||||
```
|
||||
|
||||
Ce type de prompt est particulièrement adapté aux débutants — c'est essentiellement « coller le texte officiel + exprimer ses besoins ».
|
||||
|
||||
## 8. Résumé
|
||||
|
||||
Référencer les guidelines de design pour concevoir des pages et des boutons, ce n'est pas « ressembler à quelqu'un », mais apprendre les choses suivantes :
|
||||
|
||||
1. Organiser les pages avec une hiérarchie, plutôt qu'empiler du contenu
|
||||
2. Exprimer la priorité des actions avec des niveaux de boutons, plutôt que de rendre tous les boutons également voyants
|
||||
3. Guider le design avec les définitions, les frontières et les critères de jugement des guidelines de design
|
||||
4. Quand l'IA référence les guidelines des autres, elle référence les « principes et structures », et non seulement l'habillage
|
||||
|
||||
Quand vous utilisez les guidelines de cette manière, vous ne référenciez pas seulement un style, mais une méthode de pensée de design mature.
|
||||
|
||||
---
|
||||
|
||||
## Références
|
||||
|
||||
Les liens suivants proviennent tous de systèmes de design officiels ou de la documentation officielle :
|
||||
|
||||
- Apple Human Interface Guidelines : [Overview](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
- Apple Human Interface Guidelines : [Menus](https://developer.apple.com/design/human-interface-guidelines/menus)
|
||||
- Apple Human Interface Guidelines : [Alerts](https://developer.apple.com/design/human-interface-guidelines/alerts)
|
||||
- Apple Human Interface Guidelines : [Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons)
|
||||
- Apple Archive : [How Menus Work](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/HowMenusWork.html)
|
||||
- Apple Archive : [Managing Pop-Up Buttons and Pull-Down Lists](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/ManagingPopUpItems.html)
|
||||
- Material Design : [Buttons overview](https://m3.material.io/components/buttons/overview)
|
||||
- Material Design : [Menus](https://m1.material.io/components/menus.html)
|
||||
- Microsoft Fluent 2 : [Start designing](https://fluent2.microsoft.design/get-started/design)
|
||||
- Microsoft Fluent 2 : [Menu usage](https://fluent2.microsoft.design/components/web/react/core/menu/usage)
|
||||
- Microsoft Fluent 2 : [Button usage](https://fluent2.microsoft.design/components/web/react/core/button/usage)
|
||||
- Atlassian Design System : [Foundations](https://atlassian.design/foundations/)
|
||||
- Atlassian Design System : [Button](https://atlassian.design/components/button/)
|
||||
@@ -0,0 +1,3 @@
|
||||
# Construire votre première application moderne - Conception UI
|
||||
|
||||
> Ce chapitre est en cours de rédaction, restez à l'écoute...
|
||||
+131
-64
@@ -1,115 +1,182 @@
|
||||
# Développement Full-Stack
|
||||
# Développement Junior-Intermédiaire
|
||||
|
||||
Bienvenue à l'étape **Développement Full-Stack** ! Ici, vous approfondirez le développement full-stack, maîtrisant la componentisation frontend, la conception de bases de données, le développement d'API backend et le déploiement.
|
||||
Bienvenue à l'étape **Développement Junior-Intermédiaire** ! Ici, vous approfondirez le développement full-stack, maîtrisant la componentisation frontend, la conception de bases de données, le développement d'API backend et le déploiement.
|
||||
|
||||
## Ce que vous allez apprendre
|
||||
|
||||
### Développement Frontend
|
||||
|
||||
Maîtriser le développement frontend moderne et apprendre à utiliser des bibliothèques de composants et des outils de conception :
|
||||
Maîtriser le développement frontend moderne, apprendre à utiliser des bibliothèques de composants et des outils de conception :
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 0 : Utilisation de Lovart pour les ressources"
|
||||
description="Apprendre comment utiliser des outils IA comme Lovart pour générer rapidement des ressources de jeu de haute qualité et des ressources UI"
|
||||
href="/fr-fr/stage-2/frontend/lovart-assets/"
|
||||
title="De Lovart à la création de votre propre Agent de production de ressources"
|
||||
description="De zéro, utilisez Nanobanana et Lovart pour générer massivement des ressources de conception de haute qualité, et construisez un Agent de dessin avec reconnaissance d'intention"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 1 : Introduction à Figma et MasterGo"
|
||||
description="Maîtriser les opérations de base des outils professionnels de conception UI et le flux de travail de la conception au code"
|
||||
href="/fr-fr/stage-2/frontend/figma-mastergo/"
|
||||
title="Introduction à Figma et MasterGo"
|
||||
description="Maîtriser les opérations de base des outils professionnels de conception UI et le flux de collaboration du design au code"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 2 : Construction de votre première application moderne - Conception UI"
|
||||
description="Concevoir une interface d'application web moderne à partir de zéro, en pratiquant les principes de conception UI"
|
||||
href="/fr-fr/stage-2/frontend/ui-design/"
|
||||
title="Construire votre première application moderne - Conception UI"
|
||||
description="Apprendre les bases de la conception UI pour les applications modernes"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 3 : Directives de conception UI et UI multi-produits"
|
||||
description="Apprendre les directives de conception UI dominantes pour améliorer la cohérence et l'esthétique de la conception de produits"
|
||||
href="/fr-fr/stage-2/frontend/multi-product-ui/"
|
||||
title="Concevoir des pages et des boutons en référence aux guidelines de conception UI"
|
||||
description="Apprendre les guidelines de conception UI dominantes pour concevoir des pages et des boutons avec une hiérarchie plus claire"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 4 : Construisons des portraits de Poudlard"
|
||||
description="Projet pratique : Construire une application de portraits de Poudlard interactive en utilisant des images générées par IA"
|
||||
href="/fr-fr/stage-2/frontend/llm-skills-beautiful/"
|
||||
title="Rendre l'interface attrayante avec les LLM et les Skills"
|
||||
description="Utiliser les prompts et les plugins en pratique pour que l'IA génère des interfaces belles et uniques"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/frontend/hogwarts-portraits/"
|
||||
title="Créons ensemble des portraits de Poudlard"
|
||||
description="Projet pratique : combiner des images générées par IA pour construire une application interactive de portraits de Poudlard"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/frontend/design-to-code/"
|
||||
title="Du prototype de conception au code de projet"
|
||||
description="Apprendre à transformer les prototypes des outils de conception en code frontend fonctionnel dans le navigateur"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/frontend/modern-component-library/"
|
||||
title="Mettre à jour votre interface avec une bibliothèque de composants moderne"
|
||||
description="Apprendre à utiliser des bibliothèques de composants pour construire rapidement des interfaces de niveau professionnel"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
|
||||
### Backend et Full-Stack
|
||||
### Développement Backend
|
||||
|
||||
Apprendre la conception d'API, la gestion de bases de données et les stratégies de déploiement d'applications :
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 1 : Qu'est-ce qu'une API"
|
||||
description="Comprendre le concept central des API, le pont entre frontend et backend"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 2 : De la base de données à Supabase"
|
||||
description="Maîtriser les bases des bases de données relationnelles et apprendre à utiliser Supabase, une plateforme BaaS moderne"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 3 : Code d'interface assisté par IA et documentation"
|
||||
description="Utiliser l'IA pour aider à générer du code d'interface backend et de la documentation API standard"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 4 : Flux de travail Git"
|
||||
href="/fr-fr/stage-2/backend/git-workflow/"
|
||||
title="Apprendre à utiliser Git et GitHub"
|
||||
description="Maîtriser les opérations centrales et les flux de travail de collaboration du système de contrôle de version Git"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 5 : Déploiement Zeabur"
|
||||
description="Apprendre à déployer rapidement vos applications full-stack dans le cloud en utilisant Zeabur"
|
||||
href="/fr-fr/stage-2/backend/database-supabase/"
|
||||
title="De la base de données à Supabase"
|
||||
description="Maîtriser les bases des bases de données relationnelles et apprendre à utiliser Supabase, une plateforme BaaS moderne"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 6 : Outils de développement CLI modernes"
|
||||
description="Explorer les outils CLI modernes pour améliorer l'expérience de développement dans les environnements de ligne de commande"
|
||||
href="/fr-fr/stage-2/backend/ai-interface-code/"
|
||||
title="Conception et développement d'interfaces backend d'application"
|
||||
description="Utiliser l'IA pour générer du code d'interface backend et de la documentation API standard, améliorant l'efficacité du développement"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 7 : Intégration des systèmes de paiement Stripe"
|
||||
description="Pratique : Intégrer la fonctionnalité de paiement Stripe dans votre application pour la monétisation"
|
||||
href="/fr-fr/stage-2/backend/zeabur-deployment/"
|
||||
title="Publier votre prototype de produit"
|
||||
description="Apprendre à utiliser Zeabur pour déployer rapidement votre application full-stack dans le cloud"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/backend/modern-cli/"
|
||||
title="Des IDE aux outils de programmation IA en CLI"
|
||||
description="Explorer les outils CLI modernes pour améliorer l'expérience de développement en ligne de commande"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/backend/stripe-payment/"
|
||||
title="Comment intégrer un système de paiement comme Stripe"
|
||||
description="Pratique : intégrer la fonctionnalité de paiement Stripe dans votre application pour la monétisation"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### Projets principaux
|
||||
|
||||
### Devoirs
|
||||
Les chapitres précédents consistent à apprendre les « pièces », les projets principaux consistent à apprendre « comment assembler les pièces en un produit fonctionnel, démontrable et déployable ».
|
||||
|
||||
Il est recommandé de suivre l'ordre **Projet 1 -> Projet 2** :
|
||||
|
||||
- **Projet 1** vous guide d'abord à travers la chaîne principale la plus courante des SaaS modernes : connexion, génération, base de données, paiement, console d'administration.
|
||||
- **Projet 2** vous plonge ensuite dans un scénario plus proche d'un système métier : rôles et permissions, banque de questions, examens, soumissions, console d'administration.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["Pages et composants frontend"] --> B["Base de données et interfaces"]
|
||||
B --> C["Projet 1<br/>SaaS de génération de copywriting"]
|
||||
C --> D["Paiement / Déploiement / Gestion backend"]
|
||||
D --> E["Projet 2<br/>Système d'examen en ligne"]
|
||||
E --> F["Portfolio full-stack complet"]
|
||||
```
|
||||
|
||||
Si vous ne savez pas par lequel commencer, vous pouvez vous référer à ce tableau comparatif :
|
||||
|
||||
| Projet | Compétences clés pratiquées | Pour qui | Livrable final |
|
||||
|------|------|------|------|
|
||||
| Projet 1 : Site de génération de copywriting | Structure de page SaaS, connexion utilisateur, génération IA, paiement Stripe, gestion backend | Ceux qui créent leur premier site commercial complet | Un prototype SaaS avec inscription, génération, paiement et gestion |
|
||||
| Projet 2 : Système d'examen et de gestion en ligne | Rôles et permissions, modélisation de banque de questions, flux d'examen, soumissions, correction et statistiques | Ceux qui veulent vraiment réaliser un « système métier » complet | Une plateforme d'examen avec un côté étudiant et un côté administrateur |
|
||||
|
||||
Quel que soit le projet choisi, il est recommandé de préparer au moins ces 3 livrables :
|
||||
|
||||
- Un dépôt de projet fonctionnel
|
||||
- Un lien de démonstration accessible
|
||||
- Un README et une vidéo de démonstration
|
||||
|
||||
Consolider vos compétences de développement full-stack à travers des projets pratiques :
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Devoir 1 : Construction de votre première application moderne - Full-Stack"
|
||||
description="Appliquer de manière complète ce que vous avez appris pour compléter de manière indépendante une application full-stack entièrement fonctionnelle"
|
||||
href="/fr-fr/stage-2/assignments/copywriting-platform-supabase/"
|
||||
title="Projet 1 : Première application full-stack SaaS — Site de génération de copywriting"
|
||||
description="Créer de zéro un atelier de copywriting marketing IA, couvrant connexion, génération, paiement et console d'administration"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Devoir 2 : Bibliothèque de composants frontend moderne + Trae"
|
||||
description="Utiliser des bibliothèques de composants modernes avec Trae IDE pour construire efficacement des interfaces frontend complexes"
|
||||
href="/fr-fr/stage-2/assignments/exam-management-express/"
|
||||
title="Projet 2 : Système d'examen et de gestion en ligne"
|
||||
description="Construire un système d'examen en ligne avec génération automatique de questions, passage d'examen et gestion backend"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
Si vous avez déjà terminé les deux projets principaux ci-dessus, ou si vous souhaitez construire votre portfolio selon votre propre direction technique, vous pouvez choisir un sujet approfondi parmi ces projets optionnels :
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/assignments/modern-landing-page/"
|
||||
title="Projet optionnel : Page d'atterrissage web moderne"
|
||||
description="Pratiquer l'expression de valeur, les chemins de conversion, la conception CTA et le tracking de base, pour créer une page qui convertit vraiment le trafic"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/assignments/custom-dify-agent-platform/"
|
||||
title="Projet optionnel : Plateforme d'orchestration d'agents intelligents de type Dify"
|
||||
description="Implémenter la gestion d'agents, le chat, les logs et le contrôle des permissions, pour créer une plateforme IA minimale viable"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/assignments/travel-planning-agent-platform/"
|
||||
title="Projet optionnel : Plateforme d'orchestration d'agents de planification de voyage intelligente"
|
||||
description="Autour d'entrées structurées, de l'orchestration d'agents et de la gestion de l'historique des plans, créer un produit IA de planification de voyage exécutable"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/assignments/movie-recommendation-springboot/"
|
||||
title="Projet optionnel : Système de recommandation de films Spring Boot"
|
||||
description="Combiner Spring Boot, notes et favoris avec des recommandations explicables, pour compléter un prototype de système de recommandation complet"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/assignments/simple-grocery-microservices/"
|
||||
title="Projet optionnel : Système de microservices d'épicerie fraîche"
|
||||
description="Pratiquer le fractionnement de services, le routage de passerelle, la collaboration inventaire et commandes, pour expérimenter l'approche ingénierique du monolithique aux microservices"
|
||||
/>
|
||||
<NavCard
|
||||
href="/fr-fr/stage-2/assignments/traffic-data-visualization-go/"
|
||||
title="Projet optionnel : Plateforme Go de visualisation et d'analyse de données de trafic"
|
||||
description="De l'ingestion de données, de l'agrégation par fenêtre au tableau de bord de tendances et aux alertes, créer un prototype de produit de données complet"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### Extension des capacités IA
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="IA 1 : Introduction à Dify et intégration de base de connaissances"
|
||||
description="Apprendre à construire des applications IA en utilisant Dify et intégrer des bases de connaissances privées"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="IA 2 : Recherche de dictionnaire IA et intégration d'API multimodales"
|
||||
description="Explorer plus de capacités IA, en intégrant des API multimodales comme la vision et la voix"
|
||||
href="/fr-fr/stage-2/ai-capabilities/dify-knowledge-base/"
|
||||
title="Introduction à Dify et intégration de base de connaissances"
|
||||
description="Apprendre à utiliser Dify pour construire des applications IA et intégrer des bases de connaissances privées"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
|
||||
## Pour qui c'est
|
||||
|
||||
- Développeurs avec une certaine base de programmation qui veulent apprendre systématiquement le développement full-stack
|
||||
@@ -119,7 +186,7 @@ Consolider vos compétences de développement full-stack à travers des projets
|
||||
|
||||
## Prérequis
|
||||
|
||||
- Compléter l'étape "Débutant et prototype de produit", ou avoir des connaissances de base équivalentes
|
||||
- Avoir complété l'étape « Débutant et prototype de produit », ou avoir des connaissances de base équivalentes
|
||||
- Comprendre les concepts de base de HTML/CSS/JavaScript
|
||||
- Avoir des connaissances préliminaires sur les outils de programmation IA
|
||||
|
||||
|
||||
Reference in New Issue
Block a user