J'ai un petit soucis de méthodologie concernant l'architecture de mes applications Symfony et j'espère avoir votre point de vue.

Comment faites-vous pour partager des models de données d'une application à une autres ? gérer les modifications ?

Je m'explique, je boss sur trois, quatres applications intranet que je maintient et fais évoluer (et ce nombre va augmenter au fur et à mesure du temps) et j'ai donc autant de répertoire sur mon serveur web. Toutes ces applications utilisent le même système d'identification (adLDAP) et la même base de données utilisateurs.

Mon problème résident dans le fait de devoir mettre à jour tous les models de données users lorsque je fait une modification en base, voir directement dans mes méthodes de class.

Avez-vous une méthode, une architecture spécifique pour facilité, centralisé les modifications ?

Je pensais créer un seul répertoire, du style intranet/ et mettre toutes mes applications dans le répertoire apps/, comme ça tout mes models sont centralisés dans lib/model/ et toutes mes applis ont accès au même code, même si certaines applications n'ont rien à voir entre elles.

Vous me suivez ?

En fait, ce que j'aimerais, c'est centraliser toutes mes applications au même endroit, mais je me demande si c'est vraiment propre.

Pour répondre à ton besoin, je vois 2 solutions : projet ou plugin

Projet
L'idée est de mettre toutes tes applications qui partagent ton modèle dans un même projet (sortir de l'éternel frontend et backend, et avoir 4, 5 applications ou plus dans le même projet).
L'idée qui me motive est le fait que tu partages le même modèle, donc les mêmes règles métiers, sur les mêmes données. En conséquence, tout cela reste dans le même projet.

C'est cette idée qui me semble être la meilleure.

Plugin
J'ai hésité avant de conseiller cette solution, et je te demande donc de bien lire ce que je vais écrire, et surtout le comprendre avant de la choisir.
Le plugin permet d'isoler une ou plusieurs fonctionnalité, et tout ce qui est associé (dont le modèle).
Il serait donc tout à fait possible pour toi de mettre le modèle dans un plugin et de dupliquer ce plugin de projet en projet pour le partager.

Toutefois, l'esprit même du plugin, lorsque l'on embarque un modèle, c'est de dupliquer la structure de stockage. Comprendre par là que tout les projets sur lesquels est installé le plugin ne doivent pas agir sur la même base de données, mais avec le même schéma.

Conclusion
Tu as une seule et unique base de données, où toutes les données peuvent être manipulées par tes applications => plusieurs applications dans le même projet
Tu as autant de base de données que d'application, mais tu veux que le schéma et le modèle soit partagé => plugin

PS : désolé pour le temps de réponse

Pas de soucis pour le temps de réponse, j'ai déjà commencé à tous revoir, je fais un topo dès que j'ai tous mis à plat.

Mais pour le moment, je suis parti sur multi application et multi base.

je fais un topo dès que j'ai tous mis à plat.

Comme promis.

Voici l'architecture que j'ai mise en place.

Je n'ai utiliser aucun framework connu, j'ai codé mon propre modèle MVC avec un niveau de plus que j'ai appelé Application, ce qui me donne en gros n application(s) comprenant n module(s), n vue(s) et n controller(s) et le tous utilisant les mêmes classes.

Alors pourquoi ne pas avoir utiliser un framework éxistant me direz-vous, et bien tout simplement parceque j'aime bien utiliser mes propres outils, au moins je sais ce qu'il se passe dans mes applis. De plus ce framework est spécifique à ma société et contient des objets relatifs à celle-ci (agence, region, etc...)

Arborescence de mon architecture:

--apps (répertoire contenant toutes les applications)
----global (l'application globale, qui contient le layout global, la config global, etc...)
------config
------locale(non implémenté)
------modules
------tpl
----application 1
------config (fichier de config de l'application courante)
------lib
--------model (model des objets spécifique à l'application)
------locale (non implémenté)
------modules (contient tous les controllers)
------tpl (contient les templates _list & _form de l'application)
----application 2
------config
------lib
--------model
------locale(non implémenté)
------modules
------tpl
--core (coeur du framework)
----contient toutes les classes nécessaires au bon fonctionnement du framework (core, coreAcl, coreAction, coreAgence, coreApplication, coreAutoload, coreConfiguration, coreController, coreDatabase, coreDebug, coreexception, coreFile, coreLDAP, coreMailer, coreModule, coreNTLM, coreObjectFactory, corePagination, coreQueryBuilder, coreRegion, coreRequest, coreresponse, coreRole, coreSession, coretableFactory, coreurl, coreUser, coreView, coreViewPartial)
--logs
----les logs d'erreurs
--plugins
----les plugins externes (phpMailer, phpExcel)
--scripts
----scripts divers pour l'entretien
--sql
----sauvegarde du schéma de la base
--temp
--upload (pas encore eu l'utilité, je ne sais pas si je vais laissé ça ici)
--web
----css
----img
----js
.htaccess
index.php => le bootstrap

Voila, cela me permet de gérer toutes mes applications en utilisant le même socle, authentification NTLM + LDAP, gestion des utilisateurs centralisé, etc...

J'ai quasiment fini ma deuxième applications et pour le moment ça roule.

Il y a bien des points qui ne me conviennent pas, mais je flanche pour améliorer l'ensemble.