Aller au contenu

Blog

Dossier de projet : ce que le jury lit vraiment

Un dossier n'est pas un compte rendu de ce que tu as fait. C'est la preuve que tu sais expliquer pourquoi tu l'as fait. La nuance décide de l'examen.

  • titre ASD
  • dossier de projet
  • certification
  • méthode
Évaluer, avant la grille.Salle d'examen de Dingzhou · Siyuwj · CC BY-SA 4.0

Le malentendu de départ

La plupart des dossiers que je relis souffrent du même défaut, et ce n’est pas un défaut technique. L’infrastructure tient, les scripts fonctionnent, la CI passe au vert. Le dossier raconte tout ça honnêtement, dans l’ordre, avec des captures d’écran.

Et il passe à côté.

Parce qu’un jury de certification ne cherche pas à savoir ce que tu as fait — il n’a aucun moyen de le vérifier, et ce n’est pas son rôle. Il cherche à savoir si tu comprends ce que tu as fait. Ce sont deux documents différents, et un seul des deux est évalué.

Trois symptômes

Tu peux diagnostiquer ton propre dossier en cherchant ces tournures.

« J’ai installé X. » C’est un journal, pas un dossier. La question qui manque : pourquoi X plutôt qu’autre chose ? Un jury n’attend pas la bonne réponse — il attend qu’une alternative ait été envisagée et écartée pour une raison que tu peux défendre. « J’ai choisi X parce que Y était trop coûteux à maintenir sur ce périmètre » vaut dix pages de configuration commentée.

« Comme le montre la capture ci-dessous. » Une capture d’écran ne démontre rien toute seule. Elle prouve qu’un écran a existé. Ce qui compte, c’est la phrase qui l’entoure : qu’est-ce qu’on doit y voir, et qu’est-ce que ça établit ?

Aucune trace d’un échec. Un projet qui s’est déroulé sans accroc n’existe pas. S’il n’apparaît aucune difficulté dans ton dossier, le jury en conclut l’une de deux choses : soit le projet était trivial, soit tu l’as édulcoré. Les deux te desservent. Un incident, sa cause, ce que tu as changé — c’est le passage le plus convaincant d’un dossier, et c’est presque toujours celui qui manque.

La structure qui marche

Pour chaque compétence que tu veux faire valider, un bloc court, toujours le même :

  1. La situation — le besoin, dans les termes du métier, pas de la machine.
  2. La contrainte — ce qui rendait la chose non triviale. Budget, existant, délai, compétences de l’équipe.
  3. La décision — ce que tu as choisi, et ce que tu as écarté.
  4. Le résultat — mesuré si possible, sinon observable.

Si un bloc ne tient pas en une page, ce n’est pas qu’il est riche : c’est qu’il en contient deux.

Le test du paragraphe unique

Avant de rendre quoi que ce soit, prends une compétence et écris un seul paragraphe qui l’explique à quelqu’un du métier, sans jargon d’outil, sans capture, sans liste à puces.

Si tu n’y arrives pas, ce n’est pas un problème de rédaction. C’est que la décision technique n’est pas encore claire dans ta tête — et l’entretien la mettra à nu bien plus vite que le dossier.

Si tu y arrives, tu tiens le squelette de ta soutenance en même temps que celui de ton dossier. C’est le même travail, fait une fois.

Pour aller plus loin

Cette méthode, appliquée bloc par bloc sur l’ensemble du titre Administrateur Système DevOps — avec un projet fil rouge complet, les questions du jury et des éléments de réponse — c’est l’objet du livre Décrocher le titre ASD.