Je viens de signer avec McDonald's pour développer un système de réservation d'événements, avec des relations entre plusieurs types de personnes. Ce qui m'inquiète : le projet va forcément grossir, et ils finiront par vouloir d'autres types d'activités. Mais pour l'instant, ils disent qu'ils ne savent pas encore, donc officiellement il n'y en a qu'un seul. Comment je gère ça ?

Réponse classique de client : ce « non », tu n'as pas à le prendre au pied de la lettre. Ne développe pas les cinq activités qu'ils voudront peut-être un jour. Développe la seule qu'ils ont demandée, sur un modèle qui traite les activités comme des données, pas comme de la logique codée en dur. Deux règles :

  • Prévois les points d'extension, pas les features. Les types d'activités, les rôles et les tarifs sont stockés en base : en ajouter un plus tard, c'est insérer une ligne, pas refactorer le code.
  • Masque la flexibilité. Le client ne voit qu'une seule activité, rien d'autre. Le jour où il dit oui, tu actives la nouvelle au lieu de tout reconstruire.

C'est toute la différence entre anticiper la croissance et faire de l'over-engineering : tu construis la structure maintenant, et les features uniquement quand quelqu'un les paie.

On en est à 5 types d'activités aujourd'hui, chacun avec ses propres conditions d'affichage selon le client. Merci pour le conseil. J'ai construit une base capable d'encaisser la suite :

  • De nouveaux clients et de nouveaux rôles, ajoutés sans toucher au cœur du système.
  • De nouvelles activités, chacune avec sa propre tarification, ajoutées comme des données.

Penser l'évolution dès le départ, c'est ce qui a rendu chaque ajout peu coûteux, sans jamais tomber dans l'over-engineering.

Envoyer un email à Eliott

Curriculum vitae d'Eliott Baylot

Claude est une IA et peut se tromper se trompe. Vérifiez ses réponses trois fois plutôt qu'une.