@@ -58,14 +58,14 @@ Plateformes qui permettent de bâtir des applications entières avec très peu o
| **Itération & feedback** | Toute modification du schéma (ajout d'un champ, changement de type) entraîne la régénération instantanée des écrans, garantissant que le prototype reste synchronisé avec les besoins. | Les équipes métier peuvent, via l'interface no‑code, ajuster les règles de workflow ou les champs affichés, puis republier le prototype en quelques minutes. |
| **Déploiement** | Le générateur exporte le code front‑end (HTML/CSS/JS) ou un package prêt à être intégré dans l'application finale. | Les plateformes low‑code offrent un déploiement cloud automatisé (one‑click) et la génération d'APIs pour consommer les données côté serveur. |
### Pourquoi combiner RAD avec low‑/no‑code ?
### 1.4. Pourquoi combiner RAD avec low‑/no‑code ?
-**Vitesse** : le temps de mise en place d'un prototype passe de semaines à quelques heures.
-**Flexibilité** : les changements de spécifications sont immédiatement reflétés dans l'interface, ce qui correspond exactement à l'esprit itératif du RAD.
-**Implication du client** : les utilisateurs voient rapidement un produit tangible et peuvent fournir des retours concrets, réduisant ainsi le risque d'incompréhension des besoins.
-**Réduction du coût** : moins de lignes de code à maintenir, moins de ressources de développement dédiées.
### Exemple concret (illustratif)
### 1.5. Exemple concret
1.**Modélisation** : on crée les entités `Produit`, `Facture`, `Client`.
2.**Générateur d'interfaces** : il produit automatiquement les formulaires d'ajout/modif, les listes paginées et les vues détaillées.
@@ -76,7 +76,7 @@ Plateformes qui permettent de bâtir des applications entières avec très peu o
**En résumé** : les générateurs d'interfaces et les frameworks low‑/no‑code sont les outils idéaux pour concrétiser la philosophie du RAD — prototype ultra‑rapide, itérations fréquentes, et adaptation continue aux besoins du client. Le RAD ne se limite plus à une simple méthodologie, mais s'appuie désormais sur des plateformes qui automatisent la création d'interfaces et la logique métier.
eXtreme Programming (XP) est une méthode agile conçue pour livrer rapidement un logiciel de haute qualité tout en maintenant une forte implication du client.
@@ -95,15 +95,15 @@ Elle repose sur **quatre valeurs fondamentales** (communication, simplicité, fe
| **Développement itératif** – cycles de 1 à 2 semaines (sprints courts). | Livrer un incrément fonctionnel à chaque itération. | JIRA, Azure Boards, Trello (gestion du backlog). |
| **Planning Game** (User Stories + Estimations) | Le client priorise les stories, l’équipe estime en points. | Planning Poker (online : *PlanningPoker.com*, *Scrum Poker*), Miro (tableau blanc). |
| **Planning Game** (User Stories + Estimations) | Le client priorise les stories, l'équipe estime en points. | Planning Poker (online : *PlanningPoker.com*, *Scrum Poker*), Miro (tableau blanc). |
| **User Stories** (format « As a … I want … so that … ») | Capture concise des besoins. | Confluence, Notion, GitHub Issues. |
| **Test‑Driven Development (TDD)** | Écrire d’abord le test, puis le code qui le satisfait. | JUnit/NUnit/PyTest, Jest, Mocha, Cypress (tests d’UI). |
| **Test‑Driven Development (TDD)** | Écrire d'abord le test, puis le code qui le satisfait. | JUnit/NUnit/PyTest, Jest, Mocha, Cypress (tests d'UI). |
| **Tests unitaires automatisés** | Vérifient chaque unité de code à chaque build. | JaCoCo (coverage), Istanbul (JS), Coveralls. |
| **Déploiement continu (CD)** | Livraison automatisée vers un environnement de staging ou prod. | Octopus Deploy, AWS CodeDeploy, Heroku pipelines, Netlify. |
| **Refactoring continu** | Améliorer la structure du code sans changer son comportement. | IDEs avec refactoring (IntelliJ, VS Code, Eclipse), SonarQube (qualité). |
| **Pair‑Programming** | Deux développeurs partagent un poste de travail (driver + navigator). | VS Code Live Share, Tuple, CodeTogether, Remote‑SSH. |
| **Collective Code Ownership** | Tout le monde peut modifier n’importe quel morceau de code. | Repos Git centralisés, pull‑request reviews. |
| **Collective Code Ownership** | Tout le monde peut modifier n'importe quel morceau de code. | Repos Git centralisés, pull‑request reviews. |
***Automatiser tout** : chaque changement de code doit déclencher un build + les tests unitaires.
***Maintenir la discipline du pair‑programming** : même si l’équipe grandit, garder la pratique (alternance régulière des rôles).
***Maintenir la discipline du pair‑programming** : même si l'équipe grandit, garder la pratique (alternance régulière des rôles).
***Ne jamais négliger la couverture de tests** : viser > 80 % pour garantir la sécurité du refactoring.
***Faire participer le client** : même à distance, un canal de communication instantané évite les malentendus.
***Planifier les rétrospectives** : identifier les frictions (ex. : trop de dette technique) et ajuster le processus.
@@ -146,7 +146,7 @@ Elle repose sur **quatre valeurs fondamentales** (communication, simplicité, fe
### 3.5. Résumé
**XP** se distingue par son **focus sur la qualité du code** (TDD, refactoring, pair‑programming) et **sur le feedback continu** (livraisons fréquentes, client présent). Les **outils modernes** (Git, CI/CD, IDE collaboratifs, tests automatisés) rendent la mise en œuvre d’XP plus aisée que jamais. En combinant ces pratiques avec une **culture d’équipe ouverte** et une **communication fluide**, on obtient un rythme de livraison soutenable, une dette technique maîtrisée et une satisfaction client élevée.
**XP** se distingue par son **focus sur la qualité du code** (TDD, refactoring, pair‑programming) et **sur le feedback continu** (livraisons fréquentes, client présent). Les **outils modernes** (Git, CI/CD, IDE collaboratifs, tests automatisés) rendent la mise en œuvre d'XP plus aisée que jamais. En combinant ces pratiques avec une **culture d'équipe ouverte** et une **communication fluide**, on obtient un rythme de livraison soutenable, une dette technique maîtrisée et une satisfaction client élevée.
## 4. Scrum
@@ -154,8 +154,6 @@ Scrum est un *framework* (cadre de travail) itératif basé sur des **sprints**
@@ -170,11 +168,11 @@ Scrum est un *framework* (cadre de travail) itératif basé sur des **sprints**
Un **sprint** a une durée de quelques heures à 1 mois (typique : 2 semaines). Voici les étapes de déroulement du processus :
1.**Sprint Planning** – estimation et sélection des stories du backlog.
2.**Sprint Backlog** – liste des tâches à réaliser pendant le sprint (plan d’itération).
2.**Sprint Backlog** – liste des tâches à réaliser pendant le sprint (plan d'itération).
3.**Développement** – travail quotidien, souvent en binôme.
4.**Daily Scrum (Daily Stand Up)** – réunion courte chaque jour pour partager l’avancement et les blocages.
5.**Sprint Review** – démonstration de l’incrément réalisé.
6.**Sprint Retrospective** – analyse du sprint pour s’améliorer au suivant.
4.**Daily Scrum (Daily Stand Up)** – réunion courte chaque jour pour partager l'avancement et les blocages.
5.**Sprint Review** – démonstration de l'incrément réalisé.
6.**Sprint Retrospective** – analyse du sprint pour s'améliorer au suivant.
### 4.3. Quoi (Artefacts clés) ?
On produit les documents suivants.
@@ -200,12 +198,10 @@ On produit les documents suivants.
- Description
- Estimation (points, souvent arbitraires)
- Priorité (définie par le PO, modifiable à tout moment)
- (Optionnel) Équipe assignée lorsqu’il y a plusieurs équipes.
- (Optionnel) Équipe assignée lorsqu'il y a plusieurs équipes.
-**Sprint Backlog** – tâches sélectionnées pour le sprint.
-**Increment de produit (livraison)** – version fonctionnelle à la fin du sprint.
***Sprint Backlog** – tâches sélectionnées pour le sprint.
***Increment de produit (livraison)** – version fonctionnelle à la fin du sprint.
### 4.4. Jeux sérieux (facilitation)
@@ -218,7 +214,7 @@ On produit les documents suivants.
| Buy a Feature | Priorisation économique | [Buy a Feature](https://lagrandeourse.design/blog/lexique-ux/buy-the-feature/) |
| Speed Boat | Identifier les freins et accélérateurs | [Speed Boat](https://klaxoon.com/communaute/speed-boat-une-methode-agile-a-decouvrir) |
## 4.5. Matrice de compétences (outil d’accompagnement)
## 4.5. Matrice de compétences (outil d'accompagnement)
Chaque personne de l'équipe de développement inscrit ses propres compétences dans une matrice. L'intérêt est de fixer qui est expert dans un domaine et qui souhaite apprendre.
@@ -226,7 +222,7 @@ Chaque personne de l'équipe de développement inscrit ses propres compétences
|--------|---------|----------------|
| Maîtrise | 🟢 | Expertise avérée |
| Junior | 🟡 | Connaissances de base |
| Aucun | 🔴 | Pas d’expérience |
| Aucun | 🔴 | Pas d'expérience |
> Exemple visuel :
> 
@@ -234,7 +230,7 @@ Chaque personne de l'équipe de développement inscrit ses propres compétences
### 4.5. Résumé
Scrum organise le travail autour d’un backlog priorisé par le Product Owner, découpé en user stories. Les équipes livrent des incréments fonctionnels à chaque sprint (généralement 2 semaines) en suivant un cycle : planification → daily scrums → revue → rétrospective. La flexibilité du backlog et la collaboration quotidienne (binômes, daily) permettent d’ajuster rapidement le produit jusqu’au MVP souhaité.
Scrum organise le travail autour d'un backlog priorisé par le Product Owner, découpé en user stories. Les équipes livrent des incréments fonctionnels à chaque sprint (généralement 2 semaines) en suivant un cycle : planification → daily scrums → revue → rétrospective. La flexibilité du backlog et la collaboration quotidienne (binômes, daily) permettent d'ajuster rapidement le produit jusqu'au MVP souhaité.
## 5. XP vs Scrum
@@ -247,9 +243,9 @@ Scrum organise le travail autour d’un backlog priorisé par le Product Owner,
- Gestion du travail via un *backlog* priorisé.
-**Modèle de produit**
- L’incrément de produit livré à la fin de chaque sprint.
- L'incrément de produit livré à la fin de chaque sprint.
- Le *Product Backlog* (liste ordonnée des besoins).
- Le *Sprint Backlog* (travail prévu pour l’itération).
- Le *Sprint Backlog* (travail prévu pour l'itération).
Scrum est surtout un **cadre organisationnel** : il structure la gestion du projet, mais dit peu de choses sur *comment coder*.
@@ -261,7 +257,7 @@ Scrum est surtout un **cadre organisationnel** : il structure la gestion du proj
-**Modèle de produit**
-*User stories* pour exprimer les besoins.
- Tests unitaires et d’acceptation intégrés au produit.
- Tests unitaires et d'acceptation intégrés au produit.
-**Pratiques techniques clés**
-*Pair programming*.
@@ -271,7 +267,7 @@ Scrum est surtout un **cadre organisationnel** : il structure la gestion du proj
XP est surtout une **méthode technique** : elle précise comment produire du code de qualité.
### 3. Différences et complémentarité
### Différences et complémentarité
-**Scrum** → cadre organisationnel (*qui fait quoi, quand*).
-**XP** → cadre technique (*comment coder et tester*).
- Ensemble, ils couvrent à la fois :
@@ -286,21 +282,21 @@ XP est surtout une **méthode technique** : elle précise comment produire du co
Chaque carte correspond à une tâche (user story, bug, etc.).
-**Limites WIP (Work-In-Progress)**
On fixe un nombre maximum d’items par colonne, afin d’éviter les engorgements et de favoriser la fluidité.
On fixe un nombre maximum d'items par colonne, afin d'éviter les engorgements et de favoriser la fluidité.
Exemple : pas plus de 3 tâches en "In Progress".
-**Mesure et amélioration continue**
-*Lead time* : temps total écoulé entre la demande et la livraison.
-*Cycle time* : temps passé réellement en cours de traitement.
Ces indicateurs servent à identifier les goulets d’étranglement et à améliorer le processus.
Ces indicateurs servent à identifier les goulets d'étranglement et à améliorer le processus.
-**Flux tiré (pull system)**
Contrairement à Scrum, il n’y a pas de sprints fixes.
Une tâche est tirée dans la colonne suivante dès qu’il y a de la capacité, plutôt que poussée par un planning prédéfini.
Contrairement à Scrum, il n'y a pas de sprints fixes.
Une tâche est tirée dans la colonne suivante dès qu'il y a de la capacité, plutôt que poussée par un planning prédéfini.
👉 Kanban met l’accent sur **la fluidité du flux de travail** et **l’optimisation continue**, plus que sur la planification par itérations.
👉 Kanban met l'accent sur **la fluidité du flux de travail** et **l'optimisation continue**, plus que sur la planification par itérations.
> 📚 Ressource : [Kanban – Wikipedia FR](http://fr.wikipedia.org/wiki/Kanban)
@@ -311,9 +307,9 @@ XP est surtout une **méthode technique** : elle précise comment produire du co
- La **visualisation et les limites WIP de Kanban** pour fluidifier le flux.
### Caractéristiques :
- On garde la **cadence des sprints** (comme en Scrum) pour la planification et l’inspection régulière.
- On garde la **cadence des sprints** (comme en Scrum) pour la planification et l'inspection régulière.
- On adopte le **tableau Kanban** pour mieux visualiser le travail et éviter les surcharges.
- Les limites WIP permettent d’identifier rapidement les blocages.
- Les limites WIP permettent d'identifier rapidement les blocages.
### Quand utiliser Scrumban ?
- Dans des contextes où les **priorités changent fréquemment** (projets en environnement instable ou maintenance).
@@ -324,17 +320,17 @@ XP est surtout une **méthode technique** : elle précise comment produire du co
**DevOps** est avant tout une **culture** et un ensemble de pratiques, visant à rapprocher :
- Les équipes de **développement** (Dev).
- Les équipes **opérationnelles** en charge de l’infrastructure et de la production (Ops).
- Les équipes **opérationnelles** en charge de l'infrastructure et de la production (Ops).
### Principes clés :
-**Intégration Continue (CI)**
Chaque commit déclenche des builds et des tests automatisés → détection rapide des erreurs.
-**Déploiement Continu (CD)**
Les livrables validés sont automatiquement déployés en production → mise en valeur rapide pour l’utilisateur.
Les livrables validés sont automatiquement déployés en production → mise en valeur rapide pour l'utilisateur.
-**Infrastructure as Code (IaC)**
L’infrastructure est décrite par du code versionné (ex. Terraform, Ansible, Puppet) → reproductible et auditable.
L'infrastructure est décrite par du code versionné (ex. Terraform, Ansible, Puppet) → reproductible et auditable.
-**Monitoring & Feedback**
Mise en place de métriques, logs, alertes, dashboards → boucles de rétroaction courtes pour corriger vite.
@@ -350,36 +346,34 @@ Le **Lean appliqué au logiciel** reprend les principes du *Toyota Production Sy
1.**Éliminer le gaspillage**
Supprimer les activités sans valeur ajoutée (travail inutile, attente, défauts).
2.**Amplifier l’apprentissage**
Favoriser l’expérimentation, la revue de code, les feedbacks rapides.
2.**Amplifier l'apprentissage**
Favoriser l'expérimentation, la revue de code, les feedbacks rapides.
3.**Décider le plus tard possible**
Garder de la flexibilité en différant les choix techniques jusqu’au dernier moment raisonnable.
Garder de la flexibilité en différant les choix techniques jusqu'au dernier moment raisonnable.
4.**Livrer rapidement**
Réduire les lots de travail et accélérer les cycles de livraison.
5.**Responsabiliser l’équipe**
Donner aux équipes la capacité de prendre des décisions et de s’auto-organiser.
5.**Responsabiliser l'équipe**
Donner aux équipes la capacité de prendre des décisions et de s'auto-organiser.
6.**Construire la qualité à la source**
Intégrer les tests et la qualité dès le développement (TDD, CI/CD).
7.**Optimiser le tout**
Penser en termes de système global et non d’optimisation locale (éviter de maximiser une seule équipe au détriment du flux global).
Penser en termes de système global et non d'optimisation locale (éviter de maximiser une seule équipe au détriment du flux global).
👉 L’idée centrale est de **maximiser la valeur pour le client** en améliorant en continu le processus de bout en bout.
👉 L'idée centrale est de **maximiser la valeur pour le client** en améliorant en continu le processus de bout en bout.
## 6. Comparaison des méthodes agiles et lean
| Méthode | Modèle de processus (comment on produit) | Modèle de produit (quoi on produit) | Orientation Processus | Orientation Produit |
