Conseils pour améliorer et sécuriser chaque contrôleur:

* Saisir directement dans le navigateur tous les URLs représentant les méthodes du contrôleur
* Si la méthode/URL attend des arguments, les enlever et voir ce qui se passe ;
  leur donner des valeurs illégales ou dangereuses et voir ce qui se passe.

* Si la méthode/URL est de type action attendant des arguments vendant de POSTs,
  la saisie directe de l'URL montrera les erreurs dues à l'absence de ces arguments.
* De même donner des valeurs vides, espaes, illégales et dangereuses dans les champs 
  pour voir comment ces valeurs de posts sont traités.
  
* Si la méthode/URL est de type action attendant des arguments vendant de FILEs
  la saisie directe de l'URL montrera comment l'application réagira à l'absence de fichier(s).
* De même essayer des fichiers illégaux en formats, en fausses extensions, en poids
  et voir comment l'application réagit.

* Inspecter le code de chaque méthode du contrôleur : 
  Toute action susceptible de générer une exception doit être gérée dans un bloc try/catch ;
  toutes les exceptions attendues doivent être gérées une à une ;
  Un dernier catch doit traiter l'Exception générique afin de ne pas laisser passer les exceptions encore inattendues.

Conseils pour ce qui est acceptable dans un contrôleur:

* Un contrôleur fait la navette entre l'UI et l'application.
  Il n'a pas vocation à être l'application et ne doit *PAS* contenir de logique applicative.
  Il se contente d'accepter les entrées de l'utilsateur et les passer à l'application,
  ou inversement d'envoyer les informations de l'application pour affichage à l'utilisateur.
  Ce faisant il s'assure que les erreurs ne sont pas affichées brutes à l'utilisateur 
  ou qu'elles ne soient pas bloquantes.
  
  Toutes les logiques applicatives doivent être dans les modèles
  qui contiennent à la fois des "entités" (agregate roots et entities en DDD)
  et des "services [applicatifs]" (les grandes tâches que réalise l'application).
  
  Les fonctionnalités de support qui ne sont pas spécifiques à l'application en cours
  doivent être dans les libraries (infrastructure ; emailing, logging, lecture de données, etc.).
  Elles peuvent aussi provenir de tiers et être installées via Composer dans application/third_party/.
  
  Les fonctionnalités structurantes pour le framework ou son amélioration vont dans application/core.
  Les fonctionnalités structurantes sont par exemple l'ajout mécanismes d'Observers et de Domain Events.
  Les améliorations sont l'enrichissement des classes de base des model, controller, exceptions et output.