Un site communautaire devant supporter à terme un gros trafic est un projet de long terme qui supportera différentes phases de développement fonctionnels et d’optimisation (SW mais aussi architecture).

A mon sens, la question n’est pas de savoir si tu dois faire du spécifique : plus le temps passera, plus ta part de développements spécifiques sera prédominante.

La vraie question est de savoir quelle stratégie d’implémentation retenir.
Celà dépendant de quelques paramètres :
- Quelle est la maturité de ton story board ? (elle conditionne le niveau de réactivité qu’il te faudra maintenir dans la phase de dev).
- Quel est ton Time To Market (as-tu 6 mois de dev devant toi ou dois-tu lancer d’urgence une version fonctionnelle mais non optimisée en perf)
- Quelle doit-être ton niveau fonctionnel au lancement.
- Quels sont tes objectifs de ramp-up de trafic.

En fonction de la réponse à ces questions, tu peux par exemple choisir d’utiliser views dans un premier temps pour garder beaucoup de flexibilité et prévoir de remplacer ces views par ton propre code lorsqu’elles seront figées.

L’idéal est de faire une projection du rampup attendu et de caler des releases fonctionnelles et des release d’optimisation (optimisation du code ET de l’architecture).

A partir de là, tu auras un plan de développement que tu pourras confronter à tes mesures terrains. Tu pourras alors anticiper les problèmes auxquels il faudra de toutes façons se confronter si ton site est successfull.

Pour ce qui est de CCK, pour moi la messe est dite. CCK entre dans le core et les titres et body des noeuds deviennent également des champs.
La question n’est donc plus de savoir s’il faut l’utiliser ou non, mais de savoir comment l’utiliser aux mieux. Les fils de discussions du groupe CCK sur drupal.org sont très utiles (indispensables) pour cela.

Bien sur, il n’y a pas de corrélation directe entre CCK et Views. Tu peux donc tout à fait exploiter ces champs dans tes propres modules.

Cordialement,
Erwan

Pour info (même si le sujet est marqué résolu), j’ai benché CCK comme un sauvage sans pouvoir lui trouver de problèmes, en tout cas en Drupal 6 (drupal 7, pas encore testé, et drupal 5 c’était une horreur). Pas de problème voulant dire que pour gagner du temps en faisant l’équivalent à la main, cela demande un très gros investissement pour un résultat marginal.

Pour Views, comme le dit (en simplifiant un peu) conq, Views est un bon outil de maquettage. En plus il a le bon goût de te fournir les requêtes de remplacement pour un code fait à la main. Maintenant pour Views, la problématique est inversée par rapport à CCK. Un développeur qui a une bonne expérience en PHP et connaissant bien le framework Drupal, va aller beaucoup plus vite à faire ses listes à la main qu’à les faire sur Views.

Ceci étant dit, si dans le cahier des charges ton client indique qu’il veut pouvoir modifier «simplement» les listes lui-même, c’est une autre histoire ;-)

Dernière aspect très important, l’approche performance ne sera jamais la même selon la réponse à deux questions :
- quelle est la fréquence de maj du fond (nouveau contenus, modifications, etc…)
- quel est le % d’utilisateur authentifiés attendus.

En effet, si tu as une faible fréquence de MAJ et une majorité de trafic anonyme, tout sera mangé par le cache frontal. A l’inverse, une majorité d’authentifiés avec une forte MAJ, un soin particulier doit être donné à l’optimisation.