Concevoir, maquetter, tester et documenter
Mener un projet d'infrastructure comme un professionnel : partir du besoin, choisir une solution et la justifier, la maquetter, la tester avec un cahier de recette et la documenter pour ceux qui l'exploiteront.
L'essentiel
- Un projet technique suit six étapes : analyser, choisir, maquetter, tester, déployer, exploiter ; chacune produit un livrable, et on documente tout au long.
- Une exigence est précise, mesurable et vérifiable par un test ; « fiable » ou « sécurisé » sont des souhaits à traduire.
- On recense aussi les contraintes (budget, délai, existant, compétences, juridique) et l'impact du changement.
- Le dossier de choix compare au moins trois solutions avec des critères pondérés fixés avant de noter ; total = somme des notes × poids.
- La décision est argumentée : solution retenue, raisons, risques et parades ; on raisonne en coût total (TCO).
- Maquette (Packet Tracer) → prototype (VM, labo) → pilote → production : on monte quand la marche précédente est validée.
- Tests unitaires, d'intégration, de recette et de non-régression ; sans oublier les tests négatifs et de résilience.
- Une ligne de recette : exigence, procédure, attendu, obtenu, statut, preuve ; le résultat attendu est écrit avant le test.
- Une anomalie est tracée (gravité bloquante, majeure, mineure), corrigée, retestée ; le PV prononce la recette avec ou sans réserves.
- Documentation technique (schémas physique et logique, adressage, configurations, procédures) et utilisateur ; aucun mot de passe dedans.
Une exigence = un test
Chaque exigence doit pouvoir être prouvée par un test dont le résultat attendu est écrit à l'avance. « Fiable », « rapide », « sécurisé » ne sont pas des exigences : ce sont des souhaits à traduire en chiffres, en durées ou en comportements observables.
Piège classique
Choisir d'abord la solution que l'on préfère, puis régler les poids pour qu'elle gagne. Les critères et leurs poids se fixent avec le client, avant de noter, et chaque note s'appuie sur une source (devis, documentation, essai). Un jury repère vite une grille « arrangée ».
Le cahier de recette
Il est rédigé avant les tests, à partir des exigences : une ligne = une exigence vérifiée, avec la procédure, le résultat attendu, le résultat obtenu, le statut (OK, KO, réserve) et une preuve. Il contient aussi des tests négatifs (« ceci doit être refusé »).
Piège classique
Écrire la documentation « à la fin, quand tout marchera ». À la fin, on a oublié pourquoi on a fait tel choix et la moitié des commandes. On documente au fil de l'eau : une capture, une commande, une décision notée à chaque étape. Et une documentation se met à jour à chaque modification, sinon elle devient fausse… donc dangereuse.
Repères clés
| Pour… | Repères |
|---|---|
| Écrire une exigence | précise · mesurable · un test associé · fonctionnelle ou non fonctionnelle |
| Comparer des solutions | ≥ 3 solutions · poids fixés avant (total 100 %) · note × poids · sources · risques |
| Essayer sans risque | maquette (Packet Tracer) · prototype (VM, labo) · pilote (un service) · production |
| Tester | unitaire · intégration · recette · non-régression · tests négatifs · résilience |
| Remplir la recette | N° · exigence · procédure · attendu · obtenu · OK / KO / réserve · preuve · date |
| Traiter une anomalie | bloquante · majeure · mineure → fiche, correction, re-test, non-régression, PV |
| Documenter | schémas physique et logique · adressage · configurations · procédures · version · pas de secret |