Salut.
Je dirige une toute petite entreprise pour laquelle j'envisage de faire développer d'une application qui couvrira la gestion commerciale et la gestion des différents aspects productif. La compta restant traitée à part.
Je précise que notre secteur d'activité est très confidentiel et qu'il n'existe aucune solution métier dans le commerce (j'ai écumé forums pro et salons en vain)
Pourtant nous avons de nombreux paramètres à intégrer dans notre gestion ce qui me fait de plus en plus considérer qu'il va devenir obligatoire pour nous d'avoir un outil de gestion adapté à nos besoins.
 
Avant de formuler un cahier des charges quant à nos besoins précis, cela fait plusieurs jour que j'écume forum et autres sites afin de me faire une idée précise des différentes options quant au choix du langage/univers qui sera utilisé pour ce développement.
 
Pour résumer, notre métier implique la circulation de nombreuses données ce qui me conduit à penser qu'il faudra placer au centre de tout une base de données.
N'ayant que quelques salariés (environnement windows) je pense ensuite que le plus simple et ergonomique sera d'avoir des IHM type client lourd (le client type navigateur internet ne me semble pas en mesure d'apporter la même ergonomie qu'un client dédié)
 
D'autre part, m'étant rendu compte qu'il y avait pas mal de confrères qui pourraient être interessés je souhaiterais dans un deuxième temps envisager de distribuer cette application.
Deux scenario devant être envisager : l'installation chez le client (serveur et clients) et la mise à disposition sous forme de service web (serveur hébergé + client type internet, ce qui supposerait de pouvoir utiliser les deux types de clients et bien sûr de développer dans un deuxième temps la brique client navigateur internet)
 
Ma question est donc de savoir quel environnement/langage de développement vous semble le plus adapté à ce type de projet?
JAVA, .NET, RUBY ON RAILS, DELPHI...sont les solutions que j'ai pu envisager jusqu'à maintenant...  
 
Vous remerciant d'avance.
 
 

Attention, Ruby on rail n'est pas un langage mais un framework conçu pour créer plus rapidement des sites web. Le langage, c'est Ruby.
 
 
Il n'y aurait que le client lourd, j'aurais dit Delphi ou .net (C# ou autre langage .net) ou java ou C++. Pour le ruby, je ne sais pas ce qu'il vaut pour la création de logiciel avec interface graphique.
 
S'il n'y avait qu'un couple serveur web + navigateur, j'aurais dit php, .net, java, ruby (avec ruby on rails) ou perl.
 
Vu que tu veux un client lourd avec possibilité de passer plus tard à une version client légé tout en gardant ton client lourd, alors il te faut un langage qui se sent bien dans les deux cas et qui permet de passer de l'un à l'autre sans trop de difficulté : java et les langages .net me semblent les plus adaptés.
 
Attention, je suis loin de connaitre tous les langages qui existent, il y en a peut être qui conviennent mieux à tes besoins que ceux qui j'ai cité qui sont parmi les plus connus.

+1 avec la réponse d'Omega2.
 
Sauf que quand même...
 
Déjà, chercher un ERP sur des forums euh... Tu parles de forums genre "Salons de l'entreprise" j'espère ? Pas des forums web comme celui-ci ?
 
Ensuite, tu veux connaître la techno à utiliser avant de connaître le besoin... Déjà, fait un cahier des charges, on en reparle après pour ce qui est du choix de la solution.
 
Et... Juste comme ça... Un expert en analyse sur ce genre de softs, c'est des pointures facturées à 10K€ la journée. T'es sûr que t'es capable de faire aussi bien pour ton cahier des charges ?
 
Avant de dire qu'il n'y a pas d'outils répondant à tes attentes, consulte un intégrateur d'ERP, qui pourra faire un audit de tes besoins, et t'orienter vers des éditeurs ou un dev spécifique le cas échéant.
 
Enfin, un outil de gestion, c'est pas un truc fait par un stagiaire par dessus la jambe entre deux pauses cafés. "toute petite entreprise" et "outil de gestion proprio", ça rhyme très mal. A moins que tu aies des millions d'€ à balancer par la fenêtre, ouvre ton porte monnaie et fait déjà faire un audit de tes besoins plutôt que de dire qu'il n'y a rien sur le maché (ça me ferait bien mal qu'il n'existe pas de solution déjà "toute faite" à tes besoins, par contre un truc prévu pour une activité totalement différente, ça c'est bien possible).
 
Pour rappel, un progiciel de gestion, c'est avant tout une boîte vide à qui on explique gentillement ce qu'elle doit faire. Donc faut pas t'attendre à avoir une solution clé en main pour 1000 €. Par contre "n'importe quel" ERP, correctement mis en place, peut virtuellement répondre à tes besoins, quels qu'ils soient.

Merci beaucoup pour ta réponse.
Nous sommes en train de nous orienter vers deux axes.
 
Le premier serait de developper un client lourd, à priori DELPHI afin de bénéficier des compétences d'un de nos salariés qui développe dans cet environnement. Après un usage en production qui nous aura permis d'affiner un peu le bébé, on développerait éventuellement une interface type client léger si on veut commercialiser la bête.
 
Le deuxième axe, un peu plus ambitieux serait de partir directement sur un client riche et dans ce cas on hésite entre JAVA & assimilé et un pack Apache + MySQL (ou Postgres) + PHP + AJAX .  
Cette deuxième solution aurait l'avantage d'être celle du "future" car nous croyons beaucoup à ce modèle qui devrait à terme s'imposer (selon nous...) pour les avantages qu'il offre.  
Notre seule crainte est de faire le bon choix dans la techno retenue.
A priori pour de l'AJAX qui nous semble plus souple et moins contraignat du côté client.
 
Merci beaucoup pour ta réponse Omega2.
Ces recherches sont très interessante et je suis captivé par le débat actuel qui accompagne l'évolution du modèle technologique des soft.
 

Désolé MagicBuzz, j'ai répondu avant d'avoir lu ta réponse.
Pour faire simple, vu la taille de notre entreprise, l'idéal aurait été de trouver un truc genre EBP Garagiste mais pour notre métier.
 
Le hic, c'est qu'à ma connaissance il n'existe aucune application de ce type pour notre métier (et crois moi j'ai cherché) du coup on s'est orienté vers des solutions un peu plus pro type ERP qui effectivement nous auraient offert de quoi arriver à quelque chose de chouette.
 
Vu l'investissement que cela représente, nous nous sommes rapidement dit (peu être à tort) qu'il serait plus judicieux de faire développer pour une enveloppe que nous estimons équivalente (une fois tous les coûts cachés de la mise en place d'un ERP pris en compte) quelque chose qui sera vraiment pointu et confortable; et qui surtout pourrait dans un deuxième temps être commercialisé aurpès de nos confrères qui semble-t-il ont tous un besoin équivalent.
 
 
Ce qui m'a amené à mes recherches.
Pour le cahier des charges je te rejoins car je pense aussi que "a chacun son métier" et qu'on ne s'improvise pas analyste...
Cependant nous sommes 4 salariés et il me semble qu'à raison d'une après midi par semaine on pourra faire sortir quelque chose d'assez précis quant à nos besoins.
Nous sommes assez avancé et je peux t'assurer que la formulation de nos attentes et besoins m'apparait très précise (Bon OK, c'est peut-être moins bien présenté que si c'était fait par cap Gemini mais bon ça reste quand même assez précis)
 
Pour revenir sur les ERP nous avons été en contact pour un déploiement de NAVISION qui avait l'air pas mal...
c'est juste le budget qui nous arrêté. Attention, toute chose à son prix et je ne conteste pas le faite qu'il faut que tout le monde vive.
Nous nous sommes juste dit que investir pour investir il était peu être plus judicieux de le faire dans une solution qui pourrait devenir une source de revenu étant donné que nous opérons sur un marché de niche où il existe un besoin qui n'est pas satisfait à ce jour.
 
Une fois de plus merci pour ta réponse et pour ces débats passionnants !!!

mabouilla > Juste pour savoir, si c'est pas trop indiscret, quand tu dis que c'est le prix qui vous a arrêté, ça montait à peu près dans les combien?
 
Pour ma part, j'ai déjà bossé pour un progiciel interne à une PME et je peux t'assurer qu'il faut beaucoup de temps pour arriver à un logiciel complet. Côté salaire si tu emboches quelqu'un pour ça, tu peux compter dans les 4 à 5 K€ par mois (charges salariales comprise) si tu veux quelqu'un qui a suffisamment d'expérience pour éviter les principaux couak. Si tu demandes la même chose à un indépendant ça risque de se chiffrer à beaucoup plus cher mais d'un autre côté, il pourra te proposer une base déjà existante.
 
Côté langage, je te déconseille fortement le développement en delphi si tu veux partir ensuite sur du client légé. Par expérience, c'est un langage avec lequel on a tendance à mélanger trop souvent les couches métié (gestion et traitement des données) et affichage si on ne fait pas assez attention. Quand c'est le cas, le passage d'un client lourd à un client légé est très long (beaucoup de composants delphi n'étant pas les même dans les deux cas, on se retrouve rapidement à devoir casser et refaire la moitié de ce qui a été fait)
 
MagicBuzz > Corrige moi surtout niveau salaire et tarif si tu penses que je me trompes ou que je ne suis pas assez précis.

Pour le déploiement complet, licence + developpement + hardware on était autour de 30K€
 
C'est sûr qu'on en s'attend pas à s'en sortir à 500€ à l'arrivée.
ce qu'on s'est dit c'est qu'on pourrait essayer de capitaliser l'investissement.
 

Je ne suis pas expert mais... commercialiser un applicatif de cette ampleur c'est pas exactement comme filer des powerpoints de fesse à un pote via sa cle USB, faut une structure, un support, un service commercial etc etc etc...
 
C'est difficile de juger tes besoins vu que tu précises pas trop ton activité, mais à mon sens la première étape c'est déjà de savoir ce qu'on veut faire, la technologie c'est secondaire. Et surtout c'est à un analyste confirmé d'en juger. Valoriser ses compétences en interne c'est bien, mais ca doit SURTOUT pas être ton fil conducteur qui te fait t'obstiner sur une techno (notament une impropre à ton besoin).
 
Faut pas tout mélanger en la matière quoi
 
Bon courage !
 
EDIT : 30K euros ta solution proposée ? Ma fois c'est pas si cher que ca, car t'as moins de contraintes liées au développement. Ta compétence interne elle va y passer des semaines complète à le faire, c'est tout autant une charge qu'autre chose, sans compter que ca va forcément lui prendre plus de temps à faire sa seul (ou alors c'est un dieu et par simple apposition des mains il sait débugger un programme ).

Ce que j'ai voulu dire c'est qu'il pourrait superviser les choses...Pas les faire, désolé si je me suis mal exprimé
Après pour la commercialisation, je comprend bien qu'il s'agit pas de T-Shirt avec la gueule de Chabal dessus et qu'il faudra un minimum.
le constat c'est qu'on a besoin de quelque chose qui n'existe pas vraiment. Tout le monde à bricoler tantot sous Excel, tantot sous Access et j'en passe. On se dit que si on répond déjà à notre besoin, pourquoi ne pas aller plus loin et mettre en place une structure indépendante qui s'occuperait de commercialiser cette solution (enfin ce n'est qu'une idée)
 
Merci en tout cas pour votre feedback.  
Mon probleme vient peut être du fait que je ne réalise pas vraiment ce que peut representer le travail de developpement...
Ce que je me disais c'est que ça pourrait être fait en quelques mois voire un an et que le surcout par rapport à un "simple" déploiement pourrait être amorti si d'aventure on commercialisait ce travail.

Y'a beaucoup de choses intéressantes qui se disent dans ce topic
 
Pour ce qui est de 30 K€, licence + développement + hardware, on vous a clairement menti sur un grand nombre de points je pense. Ou alors on vous a vraiment proposé un truc rudimentaire, en espérant qu'un stagiaire payé au lance pierre saura faire rentrer des ronds dans des trous carrés à grands coups de bidouilles. A mon avis, tu peux compter largement le double. Et la même chose si c'est pour faire soit-même, sâchant qu'il est fort à parier que dans 2 ou 3 ans il faudra tout remettre à plat car vous vous serez orienté à un moment où à un autre dans une impasse (de votre fait ou non, imaginez que PHP 6 ne soit absolument pas compatible avec PHP 5 par exemple).
 
Tu parles de Navision. Effectivement, pour ce qui est des tarifs, on peut espérer un truc dans ces eaux là. Pourtant, d'après ce qu'on m'a dit sur ce produit, et d'après mon expérience sur un autre ERP (Générix pour ne pas le citer), je dois dire qu'il me semble que c'est une solution à fuir. Et crois-moi, je suis pourtant réputé pour être 100% pro-Microsoft.
Navision est une micro-usine à gaz que Microsoft a racheté il y a quelques temps maintenant, et ils sont en train de le faire évoluer petit à petit vers un truc plus générique et plus propre.
Mais aujourd'hui, le constat est là : modèle des données relativement imbittable (tu crées un écran, ça te crée une nouvelle table, donc y'a pas pas deux Navision au monde avec le même MPD, ce qui garanti une maintenance honéreuse voir impossible), un langage proprio, énormément de code à la main, absolument pas paramétrable : tu veux modifier le comportement d'une fonction ? Pas de problème tu prends tes petits doigts et tu en code une nouvelle. Grmpf.
 
Dans un avenir plus ou moins proche, je dois faire un stage de formation sur cet ERP, car dans le cadre d'un partenaria avec Microsoft, ma boîte devrait développer un vertical pour Navision pour le rendre paramétrable justement. Donc j'ai pas besoin d'avoir vu le bousin pour te dire que là on part vraiment de rien... Si Microsoft fait sous-traîter à une PME comme la mienne un élément aussi important, c'est que vraiment ils n'ont rien sous la main !
 
Enfin je reste sur ma position. Je pense que le mieux c'est de faire venir un intégrateur d'ERP (pas besoin que ce soit Cap non plus) et faire un audit histoire d'être certains qu'il n'existe pas d'outil répondant à vos exigeances dans une fouchette de prix acceptable (mais tablez quand même sur 50k plutôt que 30k selon moi).
 
Si vraiment vous décidez de faire du spécifique, comme le dit Startide, n'ayez pas pour objectif de le distribuer ensuite. Il y a très peu de chances pour qu'un dev spécifique fonctionne "comme ça" dans une autre boîte. Et par expérience, parceque j'ai déjà travaillé sur de tels outils... C'est souvent de la science fiction que de rendre générique un outil spécifique. A moins que votre salarier soit expert en ERP, et qu'il aie de solides notions pour écrire ce genre de choses, vous pouvez faire une croix sur la généricité, ou alors ça vous coûtera encore le double à implémenter (sans pour autant être suffisant pour le déployer ensuite, puisqu'il y a tous les autres aspects à traîter : paramétrages, développements spécifiques, maintenance, mises à jour, etc.)
 
Dans tous les cas, si vous partez sur un objectif de faire à a fois du lourd et du léger, partez sur du Web Service : c'est la techno la plus simple à mettre en place pour être consommée ensuite par du lourd ou du léger. Seul hic, c'est plus vraiment transactionnel, du moins c'est plus lourd pour gérer les conflits de concurrence.
 
=> En gros, vous écrivez une série de web services (quelque soit le langage), qui vont TOUT faire en ce qui concerne les traîtements, la gestion des données, les éditions, etc.
=> Et consommez ces web services avec un site web et/ou un client lourd, quelque soit le langage, qui se contente de faire de l'affichage uniquement.
 
Les web services ont l'avantage supplémentaire d'être utilisables par n'importe quel outil externe, qui permettra aisément de faire des interfaces avec d'autres outils.
 
Mais bon, d'ici que vous en soyez là... Vous serez surement passé à une solution d'éditeur

C'est clair que 30k€ ... c'est a peine 6 à 8 mois de salaire d'un gas compétent payé un tarif normal. Je ne sais pas quels sont tes besoins mais j'imagine qu'ils ne sont pas des plus basiques sinon t'aurais déjà trouvé ton bonheur. A mon avis tu peux déjà multiplier ce budget par 2 ou 3 et tu risques de tomber sur la tranche basse de ce que ça te coutera en le développant en interne. Je veux bien essayer d'être plus précis en me basant sur mon expérience mais pour ça il faudrait que tu me donnes plus de détail (même si c'est en restant assez vague) soit sur le forum soit par MP.
 
Au fait, si tu veux le vendre alors à côté du coup de développement, t'auras les campagnes publicitaires à payer, le SAV (même si c'est un employé actuel qui s'y colle, c'est du temps qu'il ne passera pas à autre chose) les coups de création de la documentation et d'impression (si t'en fournis sur papier) du manuel, les évolutions futures à faire (demandé par les clients ou voulut en interne), ...  
 
En fait, à mon avis, si tu penses que tu n'arriveras pas à engranger plusieurs disaines de K€ en vendant le logiciel, les formations et l'abonnement au SAV à tes actuels concurrent (qui ont peut être déjà choisit autre chose) alors il faut que tu réfléchisses bien aux risques que tu prends pour savoir s'ils sont acceptable.
 
EDIT : grillé par MagicBuzz qui connait beaucoup mieux les ERP que moi.

Merci beaucoup encore une fois pour ces réponses...éclairantes.
Effectivement je vais peut être envisagé un changement d'épaule pour mon fusil...
Notre société intervient dans un marché de niche (en gros chaque dossier est un mouton à 5 pattes, nous ne sommes pas vraiment des industriels mais gérons un parc de dizaines de machines, la même tâche pouvant être fait plus ou moins vite sur 4 machines différentes; nous revendons des produits constitués de choses produites en interne et d'éléments achetés en externe - Bref, il faut être super organisé et disposé à mon sens d'un bon outil informatique
 
Quand je parle de commercialisation, c'est parce que nos besoins sont exactement les même que ceux de nos confrères et qu'à priori ce qui servira chez nous servira à l'identique chez nos confrères. c'est pourquoi je pense envisageable de vendre ce développement un jour.
 
Maintenant, et grâce à vous tous, il faut être réaliste et savoir se dire que ça ne vaut peut être pas le coup de réinventer la roue.
 
Aujourd'hui nous utilisons un assemblage d'exécutables ayant été développés sous Delphi (en interne) et qui viennent se piquer sur une base MySQL. ça tourne et répond à nos besoins.
Ce que nous voulions s'était remettre tout à plat et re développer quelque chose de propre et qui ne s'apparente pas à un empilement sur une base en profitant pour investir sur des technos d'avenir nous permettant d'évoluer vers des modèles type client riche...
 
Maintenant c'est sur qu'il ne faut pas perdre de vue que nous ne sommes pas Microsoft et qu'on ne peut pas non plus investir des fortunes dans un développement qui effectivement ne pourrons peut être jamais être commercialisé pour une raison ou une autre.
 
En tout cas merci beaucoup.
 

Il faut noter un truc.
 
Sur l'ERP Générix, y'a une tétrachiée de paramètres appelés AUCHANxxx, etc.
 
Si ces paramètres (utilisables par tous) portent le nom de marques, c'est pas pour rien.
 
Lorsque l'ERP est déployé dans une entreprise qui est un nouveau domaine pour l'ERP, l'éditeur de ce dernier compte bien sur cette expérience pour s'imposer dans les autres entreprises de ce domaine.
Pour cette raison, la plupart du temps, l'éditeur va faire une partie des développements spécifiques gratuitements, ou à bas prix, et en contre-partie, reste propriétaire du code spécifique.
 
C'est donc l'occasion pour avoir une solution à moindre coût qui répond à vos attentes.
 
Ceci dit, vu la description succinte de votre besoin, ça s'apparente à un outil qu'on trouve dans n'importe quelle centrale d'achat et n'importe quelle industrie d'assemblage.
 
Navision effectivement excèle dans le second domaine, mais me semble-t-il, c'est le néant pour le premier. Générix excèle dans le premier, mais j'ai jamais vu tourner son module de gestion de production (dans la base, y'a tout ce qu'il faut, mais je sais pas s'il y a du code derrière).
 
Pour les autres ERP, je ne sais pas, j'avoue que je ne connais vraiment que Générix
A coup sûr, SAP ou Oracle Applications répondent à ces deux besoins sans sourciller, mais là c'est plus 30k, mais un chèque d'accompte de 300k qu'il faut faire... juste pour avoir 50 gars qui viennent vous poser des questions deux heures un vendredi après-midi. Hors budget je pense

Carrement !!!
 
Pour l'ERP, on a déja un existant qui est opérationnel donc on ne panique pas trop.
L'ERP nous apportera peut être de nouvelles perspectives ou d'éventuels gains de productivité mais son coût les annulerait de facto !!!
Au pire on fera une bonne petite toilette à ce qu'on utilise déjà.
 
L'idée était de faire redevelopper quelque chose de plus propre et surtout d'exportable dans la perspective d'une commercialisation via une structure dédiée.
 
Merci
 
 
 

Je pense que le mieux, c'est de continuer à maintenir votre existant pour le moment. Rien ne vous empêche de le migrer petit à petit au fur et à mesure des besoins.
Mais je vous conseille de faire ça "tranquillement", c'est à dire de ne pas vraiment budgetter la chose, juste s'accorder un peu de temps quand il y a une baisse d'activité.
En tout cas, la perspective de diffusion me semble assez compromise, on se retrouve vite submergé par des détails qui obligent à tout remettre à plat. Et un client, quand il a payé pour un produit, il est très à cheval sur le moindre détail, il faut donc faire un sans faute et s'accorder beaucoup de temps pour la maintenance/évolutions.
 
Vous vous poserez la question de l'ERP lorsque vous aurez un vrai budget. Contrairement à ce que tu sembles penser, un ERP est un gain majeur aussi bien d'un point de vue productivité que financier, et ce, pour énormément de raisons :
 
A/ Réduction des coûts
- un ERP est un produit relativement "classique". Pour cette raison, pas besoin de former les utilisateurs sur le produit, on en trouve directement qui savent s'en servir à l'ANPE
- un ERP, s'il est bien paramétré, permet de prévenir des problèmes logistique, appro, évolution du marcher, etc. ainsi que de diffuser des données complexes aisément à qui de droit. c'est un gain énorme pour le quotidien, qui permet de réduire le risque d'insatisfaction client, mais aussi réduire les tâches quotidiennes telles que compiler des milliers de données pour fournir un "cockpit de contrôle" au directeur financier
- En automatisant un grand nombre de tâches, l'ERP permet de réduire les tâches répétitives au minimum. Ainsi, on peut réduire le nombre des hôtesses de saisie, et exploiter à leur plein potentiel celles qui restent, en leur faisant aussi faire des tâches à plus forte valeur ajoutée : genre plutôt que de saisir des commandes, elles peuvent faire de la démarche commerciale, entretenir des relations de confiance avec les clients, etc.
 
B/ Intégration logicielle
- Un ERP est prévu pour être interfacé avec d'autres outils, tels que des décisionels, autres ERP, etc. Ainsi, on peut contrôler les informations qu'il renferme depuis des applications tierces, et même ouvrir des fonctionnalités aux clients/fournisseurs : catalogue de vente en ligne pour les clients, interface d'appels d'offre pour les fournisseurs, suivit des prospect et litiges clients avec un CRM, etc.
- Un ERP est "standard". Vous aurez donc le choix du prestataire afin de faire de la maintenance : qu'arrive-t-il si demain l'employé qui a écrit les applis se tire ? Se tue en voiture ? (c'est ce qui c'est passé avec la tête pensante de Générix qui s'est tuée en voiture... ça avait à l'époque failli foutre en l'air la boîte, c'est réellement un risque à prendre en compte malheureusement)
 
Bon, pour le reste, je ne suis pas commercial, donc j'ai pas le panel des arguments en faveur d'un outil d'éditeur en tête Mais rien qu'avec ça, cela permet de relativiser quant au coût de mise en place. C'est un investissement sur le long terme, mais aussi une garantie. C'est un peu comme un système de sauvegarde : ça coûte très cher, ça sert à rien... jusqu'à ce que la salle serveur soit dévastée par un incendie ou par un cambrioleur. C'est ce qui décidera si la boîte met la clef sous la porte ou non.

Effectivement, vu la montagne que représente aujourd'hui une migration vers un ERP ou un developpement à 0 (merci pour vos lumières) ; ceci compte tenu du temps et des moyens nécessaires ; je pense que le plus sage serait de faire évoluer "tout doux bijou" notre application actuelle, car après tout elle fonctionne à défaut d'être super rapide et "à la pointe"
L'idée d'une commercialisation était plus un moyen de "couvrir" l'investissement dans la perspective d'un développement from the scratch d'autant plus qu'il y a à mon sens un réel besoin...
 
Bon ben on va continuer à zieuter ce qui se passe.
En tout cas toutes ces discussions et ces lectures m'auront apporté une vision plus claire à défaut loin de là d'être complète de cet univers passionnant.
 
Merci encore pour votre aide

Sinon faut mutualiser les moyens avec d'autres entreprises ayant effectivement les mêmes besoins, et vous pouvez peut être obtenir une plateforme commune ce qui permettra de faire des économies d'échelle...
 
Mais bon ca vous fait économiser au prix de la perte d'un avantage concurrentiel sur vos "adversaires". Sans parler des difficultés pour s'entendre sur l'orientation du projet...

Effectivement, ce serait une bonne solution...Mais bon comme vous dites ça risque de mal tourner !!!
Merci