Cadre et conduis un projet d'infrastructure

01Pars du besoin, pas du produit

SORIA Distribution veut ouvrir une nouvelle agence.

Une demande floue pourrait être :

"Il nous faut un serveur, un VPN et du Wi-Fi."

Ce n’est pas encore un besoin exploitable.

Commence par reformuler :

Qui travaille sur le site ?
Quels services doivent être accessibles ?
Depuis où ?
Avec quel niveau de disponibilité ?
Quelles données sont manipulées ?
Quels accès doivent rester interdits ?
Quel délai et quel budget sont imposés ?
Comment saura-t-on que la mise en service est réussie ?

Le produit vient après la compréhension du besoin.

02Écris une fiche de cadrage courte

Une fiche de cadrage utile tient d’abord sur une page.

Contexte
Ouverture d'une agence de SORIA Distribution.

Objectif
Permettre aux utilisateurs de travailler sur les services autorisés depuis le nouveau site.

Périmètre
- adressage et segmentation du site
- accès aux services internes nécessaires
- accès Internet
- poste d'administration
- supervision minimale
- documentation et recette

Hors périmètre
- refonte de l'annuaire existant
- changement du fournisseur Internet du siège
- migration des applications métier

Contraintes
- interruption minimale
- aucune donnée réelle dans le laboratoire
- changements réversibles
- budget pédagogique borné

Le hors périmètre est aussi important que le périmètre. Il empêche un projet de s’étendre sans contrôle.

03Distingue résultat attendu et moyen technique

Résultat attendu
Les utilisateurs de l'agence accèdent au service intranet avec leur identité autorisée.

Moyens possibles
VPN, routage, DNS, annuaire, règles de pare-feu, proxy, certificats...

Si tu écris directement « installer WireGuard », tu as déjà choisi une solution avant d’avoir décrit le résultat.

Le projet doit pouvoir justifier pourquoi un moyen a été retenu.

04Définis des livrables observables

Un livrable n’est pas « travailler sur le réseau ».

Exemples :

L1 — schéma logique validé
L2 — plan d'adressage
L3 — matrice de flux
L4 — configuration du laboratoire
L5 — procédure de déploiement
L6 — plan de retour arrière
L7 — recette technique
L8 — dossier de preuves
L9 — dossier d'exploitation

Chaque livrable doit pouvoir être relu ou testé par une autre personne.

05Écris les critères d’acceptation avant l’implémentation

Un critère d’acceptation transforme une phrase vague en condition vérifiable.

Si le critère n’est pas écrit avant, tu risques de choisir après coup le test qui donne le meilleur résultat.

06Découpe par dépendances

Toutes les tâches ne peuvent pas commencer ensemble.

besoin validé
→ schéma
→ adressage
→ segmentation
→ services de base
→ règles de flux
→ publication du service
→ supervision
→ recette
→ documentation finale

Exemple : tester le service par son nom dépend du DNS ; tester le DNS depuis le bon réseau dépend de l’adressage et du routage.

Une planification cohérente respecte ces dépendances.

07Utilise des jalons qui prouvent un état

Un jalon n’est pas seulement une date.

Jalon 1 — architecture approuvée
Preuve : schéma + hypothèses + risques

Jalon 2 — socle réseau validé
Preuve : adressage + routage + tests

Jalon 3 — service intégré
Preuve : accès depuis les clients autorisés

Jalon 4 — sécurité et exploitation validées
Preuve : tests négatifs + supervision + sauvegarde

Jalon 5 — recette finale
Preuve : critères d'acceptation passés ou écarts documentés

Le jalon signifie : « nous connaissons suffisamment l’état pour décider de continuer ».

08Maintiens un registre de risques

Un risque n’est pas une panne déjà observée. C’est une situation possible qui peut affecter le projet.

Risque : dépendance à un seul serveur DNS
Probabilité : moyenne
Impact : élevé
Prévention : prévoir une seconde résolution disponible
Détection : supervision de la résolution
Réponse : procédure de basculement ou restauration
Responsable : équipe infrastructure

Tu peux conserver un tableau simple :

ID | risque | probabilité | impact | action | responsable | état

Le but n’est pas de remplir un tableau pour la forme, mais d’éviter de découvrir trop tard une dépendance critique.

09Trace les décisions

Certaines décisions sont difficiles à comprendre plusieurs semaines plus tard.

Utilise une fiche courte :

Décision D-004
Sujet : protocole de routage du laboratoire
Contexte : plusieurs segments et besoin d'évolution
Options : routes statiques / OSPF
Décision : OSPF pour la partie dynamique du scénario
Raison : apprentissage du routage dynamique + évolution prévue
Conséquence : configuration et dépannage plus complexes
Limite : ne signifie pas qu'OSPF est nécessaire dans toute petite PME

Une décision documentée évite de transformer une préférence en vérité technique.

10Contrôle les changements

Quand le projet a commencé, une nouvelle demande peut apparaître :

"Finalement, il faut aussi une téléphonie IP sur le site."

Ne l’ajoute pas silencieusement.

Évalue :

impact sur le périmètre
impact réseau et QoS
nouveaux équipements
sécurité
coût
charge de travail
planning
nouveaux critères d'acceptation

Puis décide : accepter maintenant, reporter, réduire ou refuser.

11Relie projet, support et preuves

Le même travail peut produire plusieurs traces utiles :

issue ou ticket
→ décrit le besoin ou l'anomalie

commit ou changement
→ montre ce qui a été modifié

preuve technique
→ montre l'effet observé

recette
→ compare le résultat aux critères d'acceptation

journal de décision
→ explique pourquoi le choix a été fait

Ces éléments doivent pouvoir se référencer mutuellement sans contenir de secret.

12Ferme proprement un jalon

Avant de déclarer un jalon terminé :

[ ] critères d'acceptation testés
[ ] écarts connus documentés
[ ] risques mis à jour
[ ] preuves classées
[ ] procédure d'exploitation disponible si nécessaire
[ ] retour arrière connu pour les changements sensibles
[ ] décisions importantes tracées
[ ] travail restant explicitement identifié

« Terminé » ne veut pas dire « plus rien à améliorer ». Cela signifie que l’état livré est connu, vérifié et accepté selon les critères définis.