Cycle de vie d’une application

Introduction et rappels

Le cycle de vie d’un logiciel regroupe toutes les étapes allant de l’idée initiale à la mise hors service du produit : analyse des besoins, conception, développement, tests, déploiement, maintenance et évolutions.
Historiquement, on utilisait des modèles séquentiels comme le cycle en cascade ou le modèle en V, très planifiés mais rigides.
Aujourd’hui, les méthodes agiles (Scrum, Kanban…) privilégient l’itération, l’adaptation continue et l’implication des utilisateurs.
Le cycle de vie devient plus souple et continu, intégrant automatisation, qualité, sécurité et déploiements fréquents.

Dans la réalisation d’une application deux approches existent et coexistent. Le modèle itératif consiste à développer le logiciel par boucles successives : on conçoit, développe et teste une première version, puis on l’améliore à chaque itération en fonction des retours.
Le modèle incrémental livre le produit par blocs fonctionnels successifs : chaque incrément ajoute des fonctionnalités utilisables tout en s’appuyant sur les précédents.
Les deux approches permettent de réduire les risques, de détecter tôt les erreurs et d’intégrer les retours des utilisateurs au fur et à mesure, contrairement au cycle en cascade qui attend la fin pour valider.

Vision moderne du cycle de vie (SDLC : Software Development Lifecycle)

Conception produit & UX

Approche centrée utilisateur : partir des besoins réels et des usages.

Design thinking : empathie → définition → idéation → prototypage → test.

Le design thinking est une méthode de conception centrée sur l’utilisateur.
Son but : comprendre les besoins réels des utilisateurs et créer des solutions innovantes en testant rapidement des idées.
Il se déroule en 5 étapes principales :

Empathie

- - Observer et écouter les utilisateurs pour comprendre leurs besoins, frustrations, motivations.
  - Ex. : interviewer des lecteurs pour savoir comment ils recherchent un livre.

Définition

- - Reformuler le problème clairement à partir des observations.
  - Ex. : « Les lecteurs peinent à filtrer les résultats par auteur et année ».

Idéation

- - Générer un maximum d’idées (brainstorming, mind maps).
  - Ex. : moteur de recherche avec filtres dynamiques, suggestions automatiques, recherche vocale.

Prototypage

- - Créer rapidement des maquettes ou versions simplifiées pour tester les concepts.
  - Ex. : wireframes Figma ou prototype interactif d’une page de recherche.

Test

- - Faire essayer les prototypes aux utilisateurs, recueillir leurs retours, améliorer.
  - Ex. : demander à des lecteurs de tester la recherche sur un jeu de données fictif.
Du cahier des charges aux user stories :
En tant que lecteur, je veux rechercher un livre par auteur pour le trouver rapidement.
Backlog : liste priorisée (ex. US-12 Recherche par auteur, US-13 Filtres par date).
Prototypage rapide : wireframes Figma des écrans “Recherche” et “Résultats”. Cela veut dire : on dessine l’interface (boutons, champs de recherche, liste de résultats) pour valider le design avec les utilisateurs avant d’investir du temps dans le développement.

Architecture & conception technique

Choix d’architecture :

Monolithique (simple à démarrer) vs microservices (scalabilité, déploiements indépendants).

Une application monolithique regroupe tout son code dans un seul bloc, souvent déployé sur un serveur unique ou une machine virtuelle. C’est simple à héberger et à démarrer, mais pour gérer plus d’utilisateurs on doit souvent redimensionner tout le serveur (verticalement : plus de RAM/CPU).

Une architecture microservices sépare l’application en plusieurs petits services indépendants, chacun déployé sur son propre conteneur ou serveur (souvent dans le cloud avec Kubernetes ou Docker). Cela permet une scalabilité horizontale : on peut augmenter uniquement le service qui a besoin de puissance (ex. doubler les serveurs du service « recherche » sans toucher au reste).
Les microservices communiquent surtout par APIs REST ou gRPC (synchrone) et par files de messages / événements (asynchrone).
REST = simple et direct, mais fragile si un service tombe.
Les files de messages (Kafka, RabbitMQ) permettent un système plus robuste et découplé. REST (Representational State Transfer) est une façon d’échanger des données entre applications via le protocole HTTP (le même que pour les sites web).

Exemple : microservices catalogue, auth, paiement communiquant via HTTP/JSON.
Bases de données : relationnelle (PostgreSQL) pour transactions; NoSQL (MongoDB) pour contenu flexible.
Sécurité by design (DevSecOps) : chiffrement des secrets, OWASP Top 10, scans de dépendances.

Exercice : Les différentes façons de stocker des données

Objectif : découvrir les principaux modes de stockage des données et leurs usages.

Consignes

En binôme ou petit groupe, cherchez et notez les différentes façons de stocker des données utilisées aujourd’hui (au moins 5 à 6).
Pour chacune, précisez :
- Type (ex. fichiers plats, base relationnelle, NoSQL, etc.)
- Exemples de technologies (ex. MySQL, MongoDB, Redis…)
- Avantages (simplicité, performance, flexibilité…)
- Inconvénients (coût, complexité, scalabilité limitée…).
Donnez un exemple concret d’utilisation (site web, application mobile, big data…).

Aide (pistes possibles)

Fichiers plats (CSV, JSON, XML).
Bases relationnelles (MySQL, PostgreSQL, Oracle…).
Bases NoSQL (MongoDB, Cassandra, CouchDB…).
Stockage clé-valeur (Redis, DynamoDB).
Stockage objet (Amazon S3, MinIO).
Bases orientées graphes (Neo4j).
Data warehouses (BigQuery, Snowflake).

Livrable attendu

Un petit tableau
Ex. :

Type	Technologie	Avantages	Exemple d’usage
Base relationnelle	MySQL, PostgreSQL	Structurée, fiable, SQL puissant	Application e-commerce
NoSQL (document)	MongoDB	Flexible, évolutif, JSON natif	Réseaux sociaux, applis mobiles
Fichiers plats	CSV, JSON	Simple, lisible, portable	Échange de données / backups

Développement & gestion du code

Versioning :
GitFlow (branches feature/*, release/*, hotfix/*)
ou Trunk-based (petits commits fréquents + feature flags).
Revue de code : Pull Requests avec checklist (tests, lisibilité, sécurité).
Dépendances & environnements :
venv/conda (Python), npm (Node),
Docker pour un run local reproductible.
Exemple : branche feature/recherche-auteur → PR → review → merge.

Qualité logicielle & tests

Types de tests : unitaires (fonctions), intégration (services), end-to-end (parcours utilisateur), charge (JMeter).
Automatisation CI/CD : GitHub Actions/GitLab CI/Jenkins exécutent build + tests à chaque push.
Qualimétrie : couverture (ex. 80%), linters (ESLint/Flake8), analyse statique (SonarQube).
Exemple : à chaque PR, pipeline = lint → tests → rapport de couverture.

Intégration continue / Déploiement continu (CI/CD)

Build automatisé : création image Docker versionnée (ex. app:1.4.0).
Environnements : staging pour valider, puis production.
Stratégies de déploiement :
rollback rapide, feature flags pour activer une fonctionnalité progressivement,
blue/green ou canary pour réduire le risque.
Exemple : déploiement canary de la recherche par auteur sur 10% des utilisateurs.

Exploitation & maintenance

Monitoring : logs (ELK), métriques (Prometheus), alertes (Grafana/Alertmanager).
Observabilité : traces distribuées (OpenTelemetry) pour diagnostiquer une latence.
Maintenance : hotfix en production pour bug critique; mises à jour de sécurité régulières.
Exemple : pic d’erreurs 500 → rollback instantané → analyse des logs → correctif déployé.

Fin de vie du logiciel

Dette technique : suivi dans le backlog (prioriser refactoring vs nouvelles features).
Migration/réécriture : plan par lots, compatibilité ascendante, fenêtres de maintenance.
Arrêt de service : communication aux utilisateurs, export des données, archivage légal.
Exemple : module legacy remplacé progressivement par un microservice, puis décommission.

Notions avancées utiles

DevOps & DevSecOps

DevOps rapproche les équipes développement et exploitation pour livrer plus vite et plus souvent grâce à l’automatisation (tests, déploiements, monitoring).

DevOps est une approche qui rapproche les équipes Développement (Dev) et Opérations (Ops). Traditionnellement, les développeurs écrivaient le code puis le transmettaient aux administrateurs systèmes pour le déploiement ; DevOps supprime cette barrière en favorisant la collaboration et l’automatisation.
Concrètement, on utilise des outils et pratiques comme l’intégration continue (CI), le déploiement continu (CD), les tests automatisés, la surveillance en production et l’infrastructure as code (ex. Terraform, Ansible).
Le but : réduire les erreurs, accélérer la mise en production et améliorer la qualité du logiciel tout en maintenant une exploitation stable.

DevSecOps ajoute la sécurité dès le début du cycle (analyse des dépendances, scans de vulnérabilités, gestion des secrets) pour éviter de corriger après coup.

Exemple : chaque push déclenche un pipeline CI/CD qui exécute les tests, vérifie les failles de sécurité et déploie automatiquement si tout est valide.

Gestion du cycle de vie des données

Les données suivent elles aussi un cycle de vie : collecte, stockage, exploitation, archivage puis suppression.
Le respect des réglementations comme le RGPD impose la protection des informations personnelles, le droit à l’oubli et la traçabilité.

Exemple : sauvegardes régulières, chiffrement des données sensibles et anonymisation des identités pour les environnements de test.

Qualité & normes

La qualité logicielle repose sur des normes et bonnes pratiques :
ISO 25010 définit des critères comme fiabilité, performance et sécurité ;
Clean Code insiste sur la lisibilité et la simplicité ;
SOLID fournit des principes pour un code orienté objet maintenable.

Exemple : un projet bien conçu suit les principes SOLID pour éviter du code spaghetti difficile à maintenir.

🧪 TP — Améliorer la qualité d’un script Python

🎯 Objectif

Appliquer les normes et bonnes pratiques de qualité logicielle en Python :
PEP 8, Clean Code, DRY/KISS et
tests unitaires. Utiliser des outils d’analyse automatique pour
détecter et corriger les problèmes.

📂 Matériel fourni

Le fichier suivant : bad_script.py


# Script volontairement mal écrit

def moy(L):s=0
 for x in L:s+=x
 return s/len(L)

def aireRectangle(L,H):return L*H
def carre(c):return c*c
def aireTotale(liste): 
 t=0
 for f in liste:
  if f[0]=="R": t+=aireRectangle(f[1],f[2])
  else: t+=carre(f[1])
 return t

print("Moyenne:",moy([12,15,8,19]))
print("Aire totale:",aireTotale([("R",2,3),("C",4),("C",2)]))

🔧 Étapes à réaliser

Analyse du code : identifier les problèmes (nommage, indentation, duplications, lisibilité).
Utiliser un outil de qualité :
```
pip install flake8 black
flake8 bad_script.py
      
```
Lire les erreurs signalées et comprendre leur signification.
Corriger le code pour :
- Respecter PEP 8 (indentation, noms explicites, espaces, docstrings).
- Améliorer la lisibilité (Clean Code).
- Éviter la duplication (DRY) et garder les fonctions simples (KISS).
Documenter : ajouter des docstrings aux fonctions.

Tester : écrire un petit fichier de tests unitaires pour vérifier les fonctions calcul_moyenne et aire_totale.Exemple avec unittest :


import unittest
from good_script import calcul_moyenne, aire_totale

class TestCalculs(unittest.TestCase):
    def test_moyenne(self):
        self.assertEqual(calcul_moyenne([10, 20, 30]), 20)
    def test_aire(self):
        formes = [("R",2,3),("C",4)]
        self.assertEqual(aire_totale(formes), 2*3 + 4*4)

if __name__ == "__main__":
    unittest.main()

✅ Livrable attendu

Un fichier good_script.py corrigé et propre.
Un fichier test_calculs.py contenant vos tests unitaires qui passent tous.

Gestion du risque & dette technique

Chaque choix technique (framework, architecture, délais serrés) peut créer de la dette technique : du code fonctionnel mais fragile ou difficile à faire évoluer.
Identifier les risques tôt (sécurité, performance, dépendance à une techno) permet de planifier du refactoring et d’éviter les surcoûts futurs.

Exemple : repousser les tests ou ignorer les mises à jour de dépendances peut accélérer la sortie, mais rendra les correctifs ultérieurs plus coûteux.

Ce contenu est réservé aux membres du site. Si vous êtes un utilisateur existant, veuillez vous connecter. Les nouveaux utilisateurs peuvent s'inscrire ci-dessous.

Seb-Info

BTS SIO – But SD et TC

Cycle de vie d’une application