Aller au contenu
UFR Ingémedia
Retour au dossier

Phase de suivi et maintenance

Bilan, suivi post-lancement et maintenance

Réf.
Module 08 / 11
Postes
1
Contrôle
2 questions
État
—

Bilan de projet

Analyser le projet pour apprendre et s'améliorer.

Pourquoi faire un bilan ?

  • Capitaliser sur l'expérience
  • Identifier les bonnes pratiques
  • Détecter les points d'amélioration
  • Documenter pour les futurs projets
  • Célébrer les réussites

Réunion de bilan (Retrospective)

Format recommandé : "Start, Stop, Continue"

Start : Qu'est-ce qu'on devrait commencer à faire ?
Stop : Qu'est-ce qu'on devrait arrêter de faire ?
Continue : Qu'est-ce qu'on devrait continuer à faire ?
Exemple : rétrospective d'un projet de groupe étudiant (appli de covoiturage, 8 semaines)

Start (à commencer) : un point de 10 minutes chaque lundi, même si « tout va bien » ; les maquettes sur un Figma partagé plutôt que dans les DM.
Stop (à arrêter) : attendre la veille du rendu pour fusionner le code de tout le monde (3 h de conflits Git le dernier soir) ; laisser une seule personne détenir le compte Firebase.
Continue (à garder) : le canal Discord « décisions » où l'on note chaque choix validé ; la démo au prof à mi-parcours, qui a évité une fausse route.

Ce qui distingue cette rétro d'une simple discussion : chaque point est concret, daté, et devient une règle pour le projet suivant. « On aurait dû mieux communiquer » n'est pas une leçon ; « point hebdo de 10 min le lundi » en est une.

Mini-défi 30 secondes

Ton dernier projet de groupe : un Start, un Stop, un Continue. Si tu trouves les trois en moins de 30 secondes, c'est que la rétro aurait valu le coup.

Document de bilan - Structure type

1. Résumé du projet

  • Objectifs initiaux
  • Périmètre
  • Budget
  • Délais

2. Points positifs

  • Ce qui a bien fonctionné
  • Succès remarquables
  • Bonnes pratiques identifiées

3. Difficultés rencontrées

  • Problèmes techniques
  • Problèmes organisationnels
  • Imprévus

4. Leçons apprises

  • Ce qu'on ferait différemment
  • Recommandations futures
  • Best practices identifiées

5. Conclusion

  • Synthèse globale
  • Satisfaction client
  • Prochaines étapes

Indicateurs de succès - Exemple

Indicateur
Objectif
Réalisé
Écart
Budget
40k€
38k€
-5% ✓
Délais
4 mois
4.5 mois
+12% ✗
Features
100%
95%
-5% ~

Métriques à analyser

Performance

  • Temps de chargement
  • Uptime
  • Erreurs

Business

  • Taux de conversion
  • CA généré
  • ROI

Utilisateurs

  • Nombre de visiteurs
  • Taux de rebond
  • Satisfaction (NPS)

Équipe

  • Productivité
  • Satisfaction équipe
  • Turnover

Capitalisation des connaissances

Documenter pour les prochains projets

  • Templates utilisés
  • Outils efficaces
  • Estimations (pour améliorer les suivantes)
  • Contacts utiles
  • Solutions techniques réutilisables

Bilan de projet : bonne ou mauvaise leçon ?

Tri · ≈ 3 min

Projet livré avec 3 semaines de retard et 5 000 € de dépassement. Voici neuf « leçons » notées en réunion de bilan. Lesquelles sont actionnables ?

  1. Exiger la livraison des contenus (textes, photos) avant le démarrage du développement, avec une date dans le contrat.
  2. Les clients sont toujours en retard.
  3. Le développeur qui est parti n’était pas bon.
  4. Prévoir 15 % de réserve dans le budget et l’afficher au client dès le devis.
  5. Mieux communiquer.
  6. Point client de 15 minutes chaque mardi 9 h, avec un compte rendu de 5 lignes envoyé avant midi.
  7. On aurait dû choisir Shopify.
  8. Tester l’intégration du paiement dès le sprint 2, pas au sprint 6, parce que c’est la brique la plus risquée.
  9. Ne plus jamais accepter de projet avec ce client.

Post-mortem : ce projet de groupe a mal fini

Niveau 3 · Artefact : un serveur Discord · ≈ 5 min

Voici les messages clés du serveur Discord du groupe, dans le désordre. Remettez la chronologie, puis désignez la cause racine.

  1. 1Semaine 5 : le prof demande la version mobile, « c’était dans la consigne »
  2. 2« On fait un Figma d’abord ou on code direct ? » · personne ne répond, Malik commence à coder
  3. 3Rendu en retard de 6 heures, note moyenne, chacun accuse l’autre sur Discord
  4. 4Lancement du projet de site pour le festival de courts-métrages, 5 étudiants, 6 semaines
  5. 5Réunion houleuse : on garde le code, on adapte les maquettes
  6. 6Sarah livre des maquettes deux semaines plus tard, incompatibles avec ce que Malik a codé
  7. 7Nuit blanche collective la veille du rendu, le formulaire d’inscription ne marche pas

La cause racine, selon vous

Copie jaune · Cas pratique

Rédiger un bilan de projet

Analyser un projet terminé

Contexte : Vous venez de terminer un projet de refonte de site e-commerce.

Données du projet :

  • Budget prévu : 35 000€ / Réalisé : 40 000€
  • Délai prévu : 3 mois / Réalisé : 4 mois
  • Features prévues : 100% / Livrées : 90%

Difficultés rencontrées :

  • Retard dans la livraison des contenus par le client
  • Bug critique découvert en recette
  • Turnover dans l'équipe (départ d'un dev)

Succès :

  • Performance excellente (temps chargement -60%)
  • Client très satisfait du design
  • Taux de conversion +25% post-lancement

Votre mission :

  1. Rédigez un bilan structuré
  2. Identifiez 3 leçons apprises
  3. Proposez 3 actions d'amélioration pour les prochains projets
  4. Comment expliquez-vous le dépassement de budget au client ?
Correction sur le feuillet rose, réservée à l’enseignant. Elle sera commentée en cours.

Contrôle du poste

Bilan de projet

2 questions

  1. Q01MoyenScénario
    Bilan de fin de projet : budget prévu 35 000 €, réalisé 40 000 € ; délai 3 mois prévus, 4 réalisés ; conversion +25 % après lancement.

    Le client demande : « Pourquoi 5 000 € de plus que prévu ? » Que répondez-vous ?

  2. Q02FacileVrai / Faux

    Une rétrospective sert d'abord à identifier qui est responsable des retards.

Répondez à toutes les questions pour voir la correction.

Module suivant : Conclusion et ressources complémentaires