Projet final
Se connecter pour s'inscrireVotre progression
Syllabus
-
-
Objectifs
-
Validations de compétences
-
Public cible
Aucun public cible spécifié pour ce module.
-
Besoins techniques
-
Prérequis
- Aucun prérequis
-
Niveau
-
Historique du module
Aucune action enregistrée
Projet final et évaluation
-
Projet final et évaluation
Le projet
Une API web en .NET sur la LTS en vigueur, avec authentification, gestion des rôles, opérations CRUD, pagination, filtres, et une base de données réelle. Le livrable comprend les migrations, les tests et la procédure de déploiement.
Les huit critères, dans l'ordre d'importance
- l'intégrité transactionnelle : une opération multi-tables est atomique, et le test le démontre en provoquant un échec à mi-parcours ;
- l'authentification et l'autorisation : chaque route protégée l'est réellement, les rôles sont vérifiés côté serveur, jamais côté client ;
- les codes de statut : 400/401/403/404/409 sont distingués, pas fusionnés en 400 ou en 500 ;
- la gestion de l'asynchrone : aucune attente bloquante, jeton d'annulation propagé ;
- la nullabilité : aucun contournement du vérificateur sans motif écrit ;
- les requêtes : aucun défaut N+1, le nombre de requêtes par endpoint est mesuré et consigné ;
- les tests : règles de gestion, cas limites, erreurs de base. Un test d'accesseur n'est pas un test ;
- la configuration : aucun secret dans le dépôt, le même artefact fonctionne sur deux environnements.
Le critère qui départage
Le jury retient une chose : l'erreur est-elle détectable et compris ? Une application qui plante proprement avec un message exploitable vaut mieux qu'une application qui semble fonctionner et livre des incohérences. Les deux premiers critères techniques après cela sont l'annulation asynchrone et la transaction — les deux défauts que les clients signalent le plus souvent après livraison.