# Créer une application de A à Z — de la réflexion au déploiement Guide de référence : les étapes à suivre et les fichiers à créer pour organiser le travail. --- ## 1. Réflexion & brainstorming **Objectif :** clarifier le problème avant toute solution. - Quel problème je résous, pour qui, pourquoi maintenant ? - Qui sont les utilisateurs, quels sont leurs cas d'usage concrets ? - Quelle est la « douleur » actuelle et comment ils la contournent aujourd'hui ? - Quelles alternatives existent (concurrents, solutions maison) ? - Quel est le périmètre minimal (MVP) vs. « plus tard » ? - Critères de succès mesurables. **Fichiers :** - `docs/VISION.md` – le pitch en 1 page : problème, cible, proposition de valeur, ce que le produit *n'est pas*. - `docs/RESEARCH.md` – notes de recherche utilisateurs, analyse concurrentielle, hypothèses à valider. - `docs/DECISIONS/` – dossier d'ADR (Architecture/Product Decision Records), un fichier par décision importante : `0001-choix-stack.md`, etc. Format : contexte / décision / conséquences. --- ## 2. Cadrage / spécification **Objectif :** transformer l'idée validée en exigences claires. - Liste des fonctionnalités priorisées (MoSCoW : Must / Should / Could / Won't). - User stories : « En tant que…, je veux…, afin de… ». - Règles métier, cas limites, contraintes (légales, RGPD, perf, budget). - Parcours utilisateur principaux. **Fichiers :** - `docs/PRD.md` – Product Requirements Document : fonctionnalités, user stories, critères d'acceptation, hors-périmètre. - `docs/ROADMAP.md` – jalons dans le temps (MVP, v1, v2). - `docs/USER_FLOWS.md` – les parcours clés, éventuellement avec des diagrammes. --- ## 3. Conception (design & architecture) **Objectif :** décider *comment* on construit avant de construire. - **UX/UI :** wireframes → maquettes. Design system (couleurs, typo, composants). - **Architecture technique :** choix de stack (front, back, base de données, hébergement), découpage en modules/services, schéma de données, contrats d'API. - **Sécurité & données :** authentification, autorisation, chiffrement, sauvegardes. **Fichiers :** - `docs/ARCHITECTURE.md` – schéma des composants, flux de données, choix techniques et *pourquoi*. - `docs/DATA_MODEL.md` – entités, relations, schéma de BDD (+ migrations dans `migrations/`). - `docs/API.md` ou `openapi.yaml` – contrat d'API (endpoints, formats, codes d'erreur). - `docs/DESIGN.md` + maquettes (Figma lié, ou fichiers dans `design/`). - `docs/SECURITY.md` – modèle de menace, mesures. --- ## 4. Planification de l'implémentation **Objectif :** découper en tâches exécutables et ordonnées. - Découper chaque fonctionnalité en tâches de quelques heures max. - Identifier les dépendances, ce qui peut être fait en parallèle. - Définir « terminé » pour chaque tâche (tests, doc, revue). **Fichiers :** - `docs/PLAN.md` – plan d'implémentation détaillé, étape par étape, avec points de contrôle. - `TODO.md` ou un outil d'issues (GitHub Issues / Projects, Linear, Trello). - `CONTRIBUTING.md` – conventions de code, workflow git, comment lancer le projet. --- ## 5. Mise en place du projet (setup) - Init du dépôt git, structure de dossiers. - Choix de la licence, `.gitignore`. - Outils : linter, formateur, hooks pre-commit, gestionnaire de paquets. - Environnements : local, staging, production. - Squelette d'application qui démarre et affiche « Hello World ». **Fichiers :** - `README.md` – présentation, prérequis, installation, commandes principales. - `.gitignore`, `LICENSE` - `.env.example` – toutes les variables d'environnement nécessaires (sans les vraies valeurs). - Fichier de dépendances (`package.json`, `requirements.txt`, `go.mod`…). - `Makefile` ou `scripts/` – commandes standardisées (`make dev`, `make test`, `make deploy`). - Config linter/formateur (`.eslintrc`, `.prettierrc`, `ruff.toml`…). - `docker-compose.yml` / `Dockerfile` si conteneurisé. - `CLAUDE.md` – commandes du projet, conventions, pièges connus (utile pour travailler avec un assistant IA). --- ## 6. Développement **Objectif :** construire, fonctionnalité par fonctionnalité, en gardant le code toujours fonctionnel. - Une branche par fonctionnalité. - **TDD** : écrire le test qui échoue → code minimal → refactor. - Petits commits atomiques, messages clairs. - Intégration continue : à chaque push, les tests tournent. - Revue de code avant merge. **Fichiers :** - Le code source, organisé par domaine/couche. - Les tests à côté du code (`tests/`, `*_test.py`, `*.test.ts`…). - `CHANGELOG.md` – tenu à jour à chaque changement notable. - `.github/workflows/ci.yml` – pipeline CI (lint + tests + build). --- ## 7. Tests & qualité - Tests unitaires (logique isolée). - Tests d'intégration (composants ensemble, BDD). - Tests end-to-end (parcours utilisateur complet). - Tests manuels sur les cas critiques. - Revue de sécurité, audit des dépendances. - Perf : temps de réponse, charge. **Fichiers :** - `docs/TESTING.md` – stratégie de test, comment lancer chaque type. - Config de couverture de code. --- ## 8. Préparation au déploiement - Choix de l'hébergement (Vercel, Netlify, AWS, Railway, VPS…). - Configuration des environnements (secrets, variables). - Base de données de production + stratégie de migration. - Nom de domaine, HTTPS/TLS. - Monitoring, logs, alertes, sauvegardes. - Plan de rollback. **Fichiers :** - `docs/DEPLOYMENT.md` – procédure de déploiement pas à pas. - `docs/RUNBOOK.md` – quoi faire en cas d'incident (panne, restauration de backup, rollback). - `.github/workflows/deploy.yml` – pipeline de déploiement (CD). - Fichiers d'infra : `Dockerfile`, `fly.toml`, `vercel.json`, Terraform dans `infra/`… --- ## 9. Déploiement - Déployer d'abord en **staging**, tester. - Déployer en **production** (idéalement automatisé via la CD). - Vérifier : santé de l'app, logs, métriques, parcours critiques (smoke tests). - Tag de version git. --- ## 10. Post-lancement / itération - Suivre les métriques d'usage et les critères de succès définis à l'étape 1. - Collecter les retours utilisateurs, remonter les bugs. - Prioriser la suite dans la roadmap. - Boucler : retour à l'étape 2 pour la prochaine version. **Fichiers :** - `docs/METRICS.md` – ce qu'on mesure et où. - Mise à jour continue de `ROADMAP.md`, `CHANGELOG.md`, `docs/DECISIONS/`. --- ## Récapitulatif — arborescence type ``` mon-app/ ├── README.md ├── CLAUDE.md ├── CONTRIBUTING.md ├── CHANGELOG.md ├── LICENSE ├── .gitignore ├── .env.example ├── Makefile ├── docker-compose.yml ├── docs/ │ ├── VISION.md │ ├── RESEARCH.md │ ├── PRD.md │ ├── ROADMAP.md │ ├── USER_FLOWS.md │ ├── ARCHITECTURE.md │ ├── DATA_MODEL.md │ ├── API.md │ ├── DESIGN.md │ ├── SECURITY.md │ ├── PLAN.md │ ├── TESTING.md │ ├── DEPLOYMENT.md │ ├── RUNBOOK.md │ ├── METRICS.md │ └── DECISIONS/ │ ├── 0001-choix-stack.md │ └── 0002-... ├── design/ ├── infra/ ├── migrations/ ├── src/ ├── tests/ └── .github/workflows/ ├── ci.yml └── deploy.yml ``` **Pour un petit projet**, tu peux fusionner beaucoup de ces fichiers : un seul `docs/SPEC.md` (vision + PRD + archi), un `PLAN.md`, le `README.md`, et le `.env.example`. L'essentiel est de garder trace de **pourquoi** (vision, décisions), **quoi** (specs, roadmap) et **comment** (archi, plan, déploiement).