Valider le projet avant livraison

Un projet peut réussir ses tests et rester difficile à livrer : une route peut être mal reliée, une configuration de production manquer ou une mutation être accessible sans protection. Avant de mettre le carnet en ligne, vous devez vérifier les parcours réels et les contrôles qui les encadrent. Cette leçon rassemble ces vérifications dans un ordre reproductible et définit les conditions qui permettent de conclure à une livraison acceptable.

1. Préparer une validation reproductible

Lancez les contrôles depuis la racine du projet, avec la version de PHP attendue et les dépendances installées par Composer. Une validation reproductible signifie que vous notez les commandes exécutées, leur résultat et les éventuelles anomalies ; elle ne repose pas sur le souvenir d’un parcours testé manuellement. Vérifiez d’abord que la configuration de test ne pointe pas vers la base contenant des données réelles.

php -v
composer validate
composer install
vendor/bin/phpunit

La version affichée doit être compatible avec PHP 8.3. Composer valide le fichier de dépendances, puis PHPUnit affiche le nombre de tests exécutés et leur résultat. La suite doit se terminer sans échec ni erreur.

Si le projet possède des scripts Composer de vérification, exécutez aussi ceux qui sont réellement déclarés dans son fichier de configuration ; ne supposez pas qu’une commande de formatage ou d’analyse existe. Rejouez les tests après toute correction. Pour chaque échec, identifiez d’abord s’il vient du comportement, de l’environnement ou de données de test résiduelles, puis corrigez la cause au lieu de masquer le test.

2. Parcourir les comportements attendus

Complétez les tests automatisés par une vérification du carnet dans un environnement de test. Commencez sans authentification : l’accès à la liste et aux actions de gestion doit être refusé ou redirigé vers la connexion, conformément au comportement prévu. Soumettez ensuite un mot de passe incorrect, puis le bon mot de passe ; seul le second doit ouvrir l’accès. Vérifiez également que la déconnexion ferme cet accès.

Une fois connecté, créez un contact valide et vérifiez qu’il apparaît dans la liste. Modifiez-le, recherchez-le avec un terme qui doit correspondre, puis vérifiez aussi qu’une recherche sans résultat ne montre pas par erreur un autre contact. Supprimez enfin l’entrée et confirmez qu’elle ne revient pas après rechargement. Ces actions doivent utiliser les formulaires et les chemins associés par le routeur, pas un appel direct au service qui contournerait la couche HTTP.

• Utilisateur non authentifié : consultation et mutations inaccessibles.
• Authentification : mot de passe incorrect refusé, correct accepté, déconnexion effective.
• Gestion : ajout, modification et suppression observables dans la liste.
• Recherche et pagination : résultats pertinents, absence de résultats incorrects, limites respectées.
• Formulaires invalides : rejet sans écriture incohérente et message compréhensible.

3. Revoir les protections sur les requêtes

La revue de sécurité doit examiner ce que le serveur fait réellement, pas seulement la présence de composants dédiés. Pour chaque opération qui modifie des données, soumettez une requête sans jeton CSRF puis avec un jeton altéré : aucune ne doit entraîner de mutation. Vérifiez que les opérations de modification utilisent POST et que les paramètres fournis par le navigateur ne sont jamais interprétés comme des noms de colonnes ou des fragments SQL.

Entrez dans un champ de contact une chaîne contenant des caractères HTML, par exemple <script>alert(1)</script>, dans l’environnement de test. Après enregistrement et affichage dans la liste, elle doit rester du texte inoffensif ; contrôlez aussi les attributs préremplis et les messages affichés. N’effectuez pas ce test sur des données accessibles à des utilisateurs réels. Enfin, confirmez qu’une authentification réussie renouvelle l’identifiant de session et que les cookies sont configurés comme prévu pour l’environnement de déploiement.

4. Décider de la livraison

Examinez enfin les réglages propres au déploiement : secrets fournis hors du dépôt, connexion à la base prévue, affichage des erreurs désactivé pour les visiteurs et journaux exploitables sans y exposer mots de passe, jetons ou données sensibles. Confirmez que le schéma attendu est appliqué et que les données de test ne seront pas copiées dans la base de production. Les valeurs de mesure des recherches peuvent aider à repérer une régression, mais un temps satisfaisant ne remplace aucun contrôle fonctionnel ou de sécurité.

• Exécutez toute la suite PHPUnit dans un environnement isolé et consignez le résultat.
• Vérifiez les parcours complets : accès, gestion, recherche, pagination et déconnexion.
• Testez explicitement les requêtes sans jeton CSRF, les entrées HTML et les données invalides.
• Contrôlez la configuration de production, les secrets, la base ciblée et les journaux.
• Ne livrez pas tant qu’un échec ou une anomalie de sécurité reste inexpliqué.

Après ces contrôles, vous disposez d’une base de décision documentée : les tests démontrent les comportements couverts et la revue manuelle complète les risques qui ne sont pas encore automatisés.