• faire un logiciel spécifique client. Mon expérience professionnelle actuelle m'indique que c'était la méthode privilégiée il y a une dizaine d'années. Par exemple, un géant de la distribution qui développe en interne son outil de gestion d'achat aux fournisseurs.
  • faire un logiciel spécifique fonctionnellement. Limiter fonctionnellement l'étendue des possibilités d'un logiciel. Pour reprendre l'exemple précédent, le même outil de gestion d'achat ne doit pas servir à gérer les entrepôts.

Les logiciels spécifiques client ont fait la fortune des SSII qui était sollicitées pour prendre charge le développement une fois les spécifications rédigées par le client. Ce modèle semble disparaître au profit des progiciels, ces logiciels "générique client" (qui répondent à la même problématique métier de plusieurs utilisateurs).

L'industrie informatique est plutôt dans l'air des progiciels. En tant qu'éditeur, je préfère largement ce choix pour mutualiser les compétences. Oui, mais attention aux dérives d'un logiciel qui ferait tout, même le café. Par exemple, un logiciel de gestion de photos en ligne ne doit pas gérer un blog (ou un système de news, c'est pareil).

La conclusion, c'est que l'important, ce sont les interfaces entre les logiciels. Par exemple, si je veux installer un blog et une galerie photos sur mon site, il faut bien conserver deux applications séparées et trouver un moyen de les faire communiquer ou dans ce cas précis, d'homogénéiser la présentation.