Quel FrameWork choisir

Réponse acceptée !
Hello,

pour ma part - et Teclis ne sera pas surpris-, j'aurais tendance à dire plusieurs choses :
- une appli gérant l'inscription de 300 élèves à des cours ne peut pas être un truc monstrueux.
- 200 connexions simultannées (et c'est une prévision très haute à priori, d'autant plus que ça arrivera sans doute une seule fois) se gère TRES facilement sans franchement se prendre la tête à optimiser quoi que ce soit en particulier.
- les frameworks PHP...bon...lol...c'est là que le bât blesse. Déjà, je suis plutôt contre dans l'absolu : ils sont souvent lourds et proposent bien trop de possibilités par rapport aux besoins ponctuels que l'on peut avoir. Maintenant, il y a d'autres choses à considérer...et là, je vais parler en tant que développeur php senior, et responsable de dév dans une boîte :

Un framework nécessite un apprentissage, même pour un développeur senior. Cela n'a donc d'intérêt que dans le cas ou :
- ce framework facilite vraiment le dév sur le long ou le moyen terme
- ce framework est réutilisé à grande échelle...(afin de rentabiliser le temps d'adaptation)
En clair, ce n'est intéressant que pour une société développant diverses applications, fréquemment, et se basant donc toujours sur ce framework.

Dans le cadre du développement d'UNE application, je n'en vois pas l'intérêt. Pour deux raisons :
- l'apprentissage sera long pour ceux qui vont vous succéder à la maintenance du code
- le framework sera bien trop lourd puisque votre application est très spécifique

Du coup, ce que je préconiserais, moi, c'est la création de VOTRE framework, dédié à l'applicatif, et facilitant évidemment la maintenante voire l'évolution de l'application.  Parce que l'apprentissage sera bien plus court si votre framework est corretement documenté, suffisament exhaustif, et se concentrant néanmoins sur les besoins actuels et éventuels. La question à se poser alors : de quoi ai-je besoin...et de quoi suis-je susceptible d'avoir besoin un jour. En cadrant ça, on obtient une idée précise de l'architecture. On monte alors la base de données. Puis les objets. Les objets sont à classer en deux catégories : les objets spécifiques (ceux qui ont une tâche précise et actuelle), et les objets génériques (ceux qui facilitent l'implémentation de tâches éventuelles).
Il en va de même pour la base de données : suffisament concise et précise pour répondre aux besoins actuels et être compréhensible, mais suffisament souple aussi pour permettre de gérer les besoins éventuels.