La planification d’un projet informatique permet d’éviter les dérapages (notamment liés au budget, aux délais et à la qualité). Suivez ces étapes clés pour bien démarrer.

Une planification solide, ce n’est pas “faire un planning” : c’est aligner les parties prenantes, définir ce qui est livré, organiser le travail et maîtriser les risques.

1. Définir les objectifs du projet

Objectif

Clarifier pourquoi on fait le projet, pour qui, et comment on mesure le succès.

Bonnes pratiques

• Formuler des objectifs SMART : Spécifiques, Mesurables, Atteignables, Réalistes, Temporellement définis.
• Ajouter des KPI et des critères d’acceptation dès le départ (sinon, le “fini” devient subjectif).
• Distinguer :
  • Objectifs business (valeur) vs objectifs techniques (moyens)
  • Must-have vs Nice-to-have

Chiffres/repères

• Se limiter à 3 à 5 objectifs SMART maximum : au-delà, la priorisation se dilue.
• Définir 2 à 4 KPI clés (trop de KPI = pas de pilotage).

Exemple d’objectif SMART

“Réduire le temps de traitement des demandes SAV de 48 h à 24 h d’ici le 30/06, en mettant en place un portail de tickets et une base de connaissances, avec un taux de satisfaction utilisateur ≥ 4/5.”

Livrables attendus

• Note de cadrage (1–2 pages) : contexte, objectifs SMART, KPI, périmètre, jalons.
• Définition de Done / critères d’acceptation (même en mode cycle en V).

2. Identifier les parties prenantes

Objectif

Éviter les blocages : qui décide, qui valide, qui exécute, qui est impacté ?

Bonnes pratiques

• Cartographier les parties prenantes : Sponsor / MOA / Utilisateurs / IT / Sécurité / Juridique / Exploit / Support / Fournisseurs.
• Utiliser une matrice RACI pour chaque livrable clé (cahier des charges, tests, mise en prod…).
• Anticiper la conduite du changement : qui perd quoi ? qui gagne quoi ?

Chiffres/repères

• 1 sponsor clairement identifié (et disponible) : sinon, arbitrages impossibles.
• 1 décision = 1 décideur (sinon consensus infini).
• Prévoir au moins 1 représentant utilisateur par grand profil (ex : back-office + front-office).

Exemple de RACI (extrait)

• R (Responsable) : Chef de projet IT
• A (Accountable / “redevable”) : Sponsor métier
• C : RSSI, DPO, Exploitation, Achats
• I : Support, équipes impactées

Livrables attendus

• Carte des parties prenantes (influence / impact)
• RACI + liste des comités (rôles, fréquence, règles d’arbitrage)

3. Établir le cahier des charges

Objectif

Définir ce qui est inclus / exclu, es exigences, les contraintes et les critères de validation.

Bonnes pratiques

• Structure recommandée :
  1. Contexte & objectifs
  2. Périmètre (IN/OUT)
  3. Exigences fonctionnelles (user stories ou spécifications)
  4. Exigences non fonctionnelles (perf, sécurité, SLA, accessibilité)
  5. Contraintes (SI, réglementaire, budget, planning)
  6. Données & interfaces (API, flux, formats)
  7. Stratégie de test & recette
  8. Modalités de déploiement & support
• Formaliser les hypothèses et dépendances (souvent oubliées).
• Définir dès maintenant comment gérer le change request (sinon scope creep).

Chiffres/repères

• Viser 10 à 25 exigences fonctionnelles bien écrites plutôt que 80 floues.
• Ajouter 5 à 10 exigences non fonctionnelles minimum (sécurité, dispo, sauvegarde, RTO/RPO, performance, audit…).
• Pour réduire l’ambiguïté : chaque exigence devrait être testable (critère de recette).

Exemple

“L’utilisateur peut créer un ticket en ≤ 2 minutes, avec pièces jointes jusqu’à 10 Mo, et reçoit un email de confirmation en moins de 60 secondes.”

Livrables attendus

• Cahier des charges (ou backlog) validé
• Règles de gestion du périmètre (process de demande de changement)

4. Planifier ressources et délais

Objectif

Transformer le besoin en plan exécutable : tâches, charges, dépendances, jalons.

Bonnes pratiques

• Découper en WBS (Work Breakdown Structure) : lots → sous-lots → tâches.
• Estimer avec des méthodes simples :
  • 3 points : Optimiste / Probable / Pessimiste
  • Planning poker (Agile) ou PERT (si tu veux raffiner)
• Identifier le chemin critique (les tâches qui font bouger la date finale).
• Réserver du temps pour ce qui est souvent oublié : tests, recette, correction, documentation, accompagnement, déploiement, run.

Chiffres/repères utiles

• Répartitions typiques (repères) :
  • Dév/paramétrage : 40–60 %
  • Tests + correction : 20–35 %
  • Recette métier : 10–20 %
  • Déploiement & conduite du changement : 10–20 %
• Prévois un buffer :
  • Projet connu / peu risqué : 10 %
  • Projet multi-équipes / dépendances : 15 %
  • Projet innovant / incertain : 20 %

Exemple de mini-planning

Projet “Portail de tickets” – 8 semaines

• S1 : cadrage + ateliers (2–3 ateliers de 2 h)
• S2–S4 : build (sprints ou lots)
• S5 : tests système + corrections
• S6 : recette métier (scénarios + PV)
• S7 : préparation déploiement + formation (sessions 1 h)
• S8 : mise en prod + hypercare (5 jours)

Livrables attendus

• Planning (Gantt / roadmap / plan de release)
• Plan de charge (qui fait quoi, quand)
• Jalons + critères de passage (Go/No-Go)

5. Évaluer les risques

Objectif

Anticiper les obstacles et éviter le mode “pompier”.

Bonnes pratiques

• Tenir un RAID log : Risks, Assumptions, Issues, Dependencies.
• Utiliser une matrice simple Probabilité (1–5) x Impact (1–5) = score (1–25).
• Pour chaque risque : prévention + plan B + propriétaire + date de revue.

Chiffres/repères

• Sur un projet standard, vise 10 à 20 risques identifiés au cadrage (oui, c’est normal).
• Revue risques hebdo en équipe, mensuelle en comité.

Exemples de risques + parades

• Risque : dépendance à une API externe instable
  • Prévention : tests de charge + SLA contractuel
  • Plan B : mise en cache / mode dégradé
• Risque : disponibilité métier insuffisante pour la recette
  • Prévention : réserver les créneaux dès le planning
  • Plan B : recette par “key users” + scénarios prioritaires

Livrables attendus

• Registre des risques (score, responsable, plan d’action)
• Plan de continuité / déploiement progressif si nécessaire

6. Instaurer un suivi régulier

Objectif

Garder le contrôle et détecter tôt : « plus tôt tu vois, moins ça coûte ».

Bonnes pratiques

• Mettre en place une routine de pilotage :
  • Point projet hebdo (30–45 min) : avancement, risques, décisions
  • Daily (15 min) si équipe de dev dédiée (Agile)
  • Comité de pilotage (toutes les 2–4 semaines) : arbitrages, budget, planning
• Suivre 4 indicateurs simples :
  • Avancement (livrables terminés vs planifiés)
  • Qualité (défauts, taux de réussite des tests)
  • Délais (écarts et chemin critique)
  • Risques (score total, nouveaux risques, issues ouvertes)

Chiffres/repères

• 1 compte rendu (CR) en ≤ 24 h après chaque comité.
• Un tableau de bord 1 page (pas un roman) : lisible par un sponsor en 2 minutes.

Exemple concret de “tableau de bord 1 page”

• Statut global : 🟢/🟠/🔴
• 3 faits marquants de la semaine
• 3 risques majeurs + plans
• Décisions attendues du sponsor (avec date limite)
• Prochain jalon + critères

Livrables attendus

• Comptes rendus + plan d’action (qui/quoi/quand)
• Dashboard projet
• Procès-verbal de recette + Go/No-Go