Comment passer l'examen blanc PSD-I ?

Cliquez sur le bouton « Commencer l'examen » sur cette page pour accéder à l'examen blanc PSD-I en ligne, gratuitement, avec correction immédiate à la fin.

Quel est le seuil de réussite ?

Le seuil de réussite varie selon la certification officielle.

Puis-je refaire l'examen plusieurs fois ?

Oui, autant de fois que vous le souhaitez.

Les corrections sont-elles fournies ?

Oui, chaque réponse est expliquée en détail.

Examen PSD-I — PSD-I — Professional Scrum Developer I (PSD I) | Questions d'entraînement

À propos de l'examen PSD-I

L'examen PSD-I — PSD-I — Professional Scrum Developer I (PSD I) — est proposé par Scrum.org et fait partie des certifications IT les plus reconnues au niveau international. Cette épreuve évalue vos compétences pratiques et théoriques dans le domaine de professional scrum developer i (psd i). L'entraînement Certifexpress comprend 40 questions au format officiel pour une durée de 80 minutes. Sur cette page, découvrez 5 exemples de questions représentatives pour évaluer votre niveau avant de commencer l'entraînement complet.

Comment se préparer à l'examen PSD-I ?

Révisez les concepts clés couverts dans le guide officiel de l'examen PSD-I.

Entraînez-vous régulièrement avec des questions au format réel pour vous familiariser avec la structure de l'épreuve.

Identifiez vos points faibles grâce aux explications détaillées fournies après chaque réponse.

Gérez votre temps : simulez les conditions réelles de l'examen en vous chronométrant.

Rejoignez la communauté Certifexpress pour partager vos retours d'expérience avec d'autres candidats.

5 exemples de questions — PSD-I

Ces questions sont extraites aléatoirement de la banque de questions officielle. Les réponses correctes ne sont pas indiquées ici — elles sont révélées lors de l'examen complet.

Qu'est-ce que l'approche 'Test-Driven Development' (TDD) et quel bénéfice apporte-t-elle au-delà de 'juste avoir des tests' ?

A TDD = écrire le test AVANT le code (Red-Green-Refactor). Force le design par les cas d'usage ; crée des contrats explicites avant implémentation. B TDD signifie avoir une haute couverture de tests : écrire les tests en même temps que le code pour maximiser couverture et qualité. C TDD est juste un processus de nomenclature : mettre 'Test' en avant du développement signifies que tester est prioritaire, code second. D TDD force l'équipe à écrire tous les tests d'abord, puis l'implémentation. Les tests déterminent le design final du code produuit.

Qu'est-ce que la 'couverture de code' (code coverage) et quels sont les pièges courants d'une couverture à 100% ?

A Pourcentage de lignes/branches exécutées par les tests. 100% ne garantit pas l'absence de bugs : les assertions peuvent être triviales ou manquer des paths logiques. B Métrique qui représente la qualité des tests. 100% de couverture signifie que tous les bugs ont été trouvés avant la prod. C Mesure du nombre de tests unitaires écrits relative aux nombres de fonctions. 100% signifie que chaque fonction a au moins un test. D Statistique qui aide à identifier le 'dead code'. Augmenter la couverture à 100% supprime automatiquement les branches non atteignables.

Qu'est-ce que l'inversion de dépendances et pourquoi est-ce crucial pour la testabilité d'une architecture en couches (présentation, métier, persistence) ?

A Abstraire les dépendances via des interfaces : les couches hautes dépendent d'interfaces, pas de l'implémentation concrète, permettant l'injection de mocks. B Placer toutes les dépendances dans une couche centrale d'injection, et faire que chaque module importe de cette couche centrale. C Reverser l'ordre des dépendances : faire que persistence appelle métier qui appelle présentation pour qu'aucune couche ne dépende des autres. D Utiliser un conteneur d'injection de dépendances qui automatiquement remplace les dépendances réelles par des mocks durant les tests.

Qu'est-ce que le 'refactoring' et comment diffère-t-il d'une réécriture ('rewrite') en termes de risque et vélocité ?

A Refactoring préserve le comportement observable via des petits changements testés pas à pas. Rewrite recrée de zéro : plus risqué, plus lent. B Refactoring fait des changements au code existant ; rewrite crée une version parallèle. Refactoring est plus rapide mais rewrite plus sûr. C Refactoring améliore la qualité via refonte progressive ; rewrite accepte la qualité existante. Refactoring garantit zéro régressions. D Refactoring s'applique quand la codebase est petite (< 1000 lignes) ; rewrite pour les gros monolithes (> 100k lignes).

Qu'est-ce que la 'refactorisation de legacy code' et quel pattern est essentiel pour démarrer sans tout casser ?

A Changer le code existant sans dépendre des tests. Pattern clé : isoler progressivement les dépendances, ajouter des tests pour chaque isolation, refactor incrémentiellement. B Réécrire du legacy code en patterns modernes (SOLID, Clean Code). Essayer de minimiser les changements comportementaux pendant la refonte. C Documenter le legacy code pour comprendre son intention, puis refactoriser en parallèle dans une branche de longue durée avant merge. D Ajouter une couche d'abstraction au-dessus du legacy code pour l'isoler. Les nouveaux codes utilisent cette couche, legacy reste inchangé.

Encore 35 questions dans l'examen complet

Accédez à toutes les questions avec corrections détaillées et explications officielles.

Commencer l'examen — Gratuit

✓ Sans inscription obligatoire · Correction immédiate

📖 Préparez-vous avec nos guides

Salaires & Certifications IT 2026

Commencer l'examen PSD-I complet

40 questions au format officiel, corrections détaillées, suivi de votre progression. Gratuit, sans CB.

Commencer l'examen complet →