robinsonvendredi

Il est possible d'avoir un contrat de SLA (service level agreement) avec son hébergeur, l'obligeant à fournir en cas de crash un serveur dédié identique à celui qu'il a fourni d'origine, sous un délai de 3 heures par exemple. IL faut que le contrat comporte une clause de pénalité en cas de dépassement du délai. Evidemment ce type de contrat a un coût (demande des devis aux différents hébergeurs) et d'autre part, il faut une solution de sauvegarde permettant de restaurer les fichiers et les données dans un délai acceptable. L'hébergeur peut aussi s'engager sur une procédure de sauvegarde, ce qui engendre un coût supplémentaire. En ce qui me concerne, soit je maintiens seul mes applis sur mes serveurs, soit je travaille avec une société qui distribue les logiciels, en assure la maintenance applicative, la hotline, etc...Le coût est encore supérieur. Si tu es en mutualisé, à ma connaissance les hébergeurs ne garantissent pas de délai, mais c'est à vérifier dans leurs contrats-types. En principe il y a un backup quotidien, le temps pour l'hébergeur de traiter ta demande, de remonter un hébergement et de restaurer, est extrèmement variable. de quelques heures à plusieurs jours selon le pays de ton hébergeur, ses jours fériés, etc...

Elle fait surtout le malheur des informaticiens comme dit ludo88, et celui des "vraies" entreprises qui sont leurs clientes et doivent payer de plus en plus cher en pub. De mon point de vue Google est toujours aussi pertinent qu'avant, c'est seulement le paysage qui a changé.

Au risque de lancer un pavé dans la mare, l'Open Source et le web 2.0 arrangent bien Google. Depuis 5-6 ans, le web s'est dé-professionnalisé : les sites d'entreprises "sérieuse" sont moins présents dans les résultats des moteurs, (ils sont noyés dans la masse des contenus perso) d'où leur présence corrigée à grand renfort de pub. S'il fallait payer un logiciel de forum ou e-commerce B2C à son vrai prix, les gens réfléchiraient un peu avant de lancer n'importe quoi, il y aurait moins de contenus "divers et variés" mais aussi moins d'utilisateurs et moins de pubs adsense et autres.

syntaxe sql server : SELECT Table.champ FROM Table FOR XML RAW, ELEMENTS Mais il existe des variantes, à voir la doc MS Désolé je ne sais pas si c'est possible avec mysql. Pour ce qui est de manipuler le DOM, il doit bien y avoir des tutoriels XML pour ton langage de prédilection. Mon code est en vb si ça peut t'interesser ...

J'ai indiqué les solutions que j'ai utilsé au vu du topic, mais ce n'est certes pas une solution à ton extension de classe php. Bon courage.

Certaines bases de données permettent de générer un fichier XML avec une simple commande SQL = une ligne de code . Sinon, on peut créer des noeuds Table, Ligne, Colonne, et construire un document DOM à l'aide des méthodes createElement et AppendChild en lisant en boucle les données de la base où à partir d'un array comme tu le suggères. Pour ce qui est de l'encodage, perso j'utilise ISO-8859-1

Dans l'exemple que tu donnes : Les pré-sélecteurs 'votre lieu de travail' peuvent être réalisés avec un script AJAX, tape 'combo box Ajax' sur Google et tu devrais trouver ton bonheur. Les préselecteurs permettent d'obtenir les sélecteurs définitifs pour la recherche, ils ne sont que des filtres sur les champs de la base et ne présentent pas de difficulté particulière. Seul le champs 'intitulé du poste' correspond à un problème classique de moteur de recherche et nécessite un algorithme complexe (rapprochement de mots, synonymes, etc). On trouve en effet des scripts déjà développés sur Internet permettant de résoudre ce problème. Le champs 'société' est une recherche textuelle sur nom propre avec pour seule complexité à résoudre les erreurs d'orthographe sur les noms. Un algo de type SOUNDEX peut permettre de venir à bout du problème. A toi d'assembler le tout.

Tu évoques les questions les plus classiques : solutions propriétaires / Open source, personnalisation et pérennité de la solution. Malheureusement il n'existe pas de réponse miracle et pas cher. Dès lors que tu souhaites des fonctionnalités précises (un site qui ressemble à celui de ...) il ne faut pas croire que ce sera fait en trois coups de cuiller à pots, et l'informatique sur-mesure coûte cher. L'apparente simplicité des sites web est trompeuse, certaines chose ont l'air simples mais elles demandent plus de travail qu'il n'y parait. Donc à partir du moment où tu as un système personnalisé il y a X lignes de codes sur mesure. En cas de changement de prestataire, le nouveau refera systématiquement le site en partant de zéro : soit pour bénéficier d'une dernière version du logiciel (Open source ou pas), soit pour remettre à niveau les fonctionnalités, ou tout simplement pour ne pas avoir à déchiffrer un code qui n'est pas le sien. Pour ce qui est du prestataire, les clients TPE et PME préfèrent s'adresser à des sociétés de prestation de service les plus importantes possible, en pensant qu'elles sont plus pérennes. C'est faux pour les prestataires "à taille humaine", en fait il y a un tel taux d'échec dans les secteurs liés à l'Internet que les boîtes qui ont tenu le coup depuis fin 2000 sont plutôt rares. Donc moralité, si tu veux des fonctionnalités sur mesure il faut accepter d'en payer le prix et de courir le risque d'avoir une solution fermée qu'elle soit Open Source ou pas : dans les deux cas attend toi à repayer un nouveau site tous les 3 à 5 ans en moyenne. L'autre option c'est de demander une installation basique d'un logiciel, dans ce cas tu oublies amazon et la fnac. Pour un débutant sur Internet cette option est la plus sage, il vaut mieux mettre le paquet sur le marketing que sur le développment AMHA.

Au temps pour moi ! si tu concrétises l'idée, tiens nous au courant.

Parfois il arrive aussi qu'on facture un nombre d'heures en sachant qu'on en passera plus, si le projet est prometteur en termes de référence. D'après le travail préparatoire que vous semblez avoir fait, vous devriez avoir satisfaction, c'est ce que je vous souhaite en tous cas.

= Le nombre de jours de travail du prestataire pour adapter le logiciel standard à vos besoins, créer les contenus le cas échéant, la charte graphique, etc... En pratique, un budget de 1500 représente environ 20 heures de travail en tout et pour tout. Sur ce budget, il ne faut pas oublier qu'une grande partie du temps de travail passe dans des tâches non productives : prospection, rendez vous avec le client, rédaction du devis, conversations au téléphone etc...si on ajoute les corrections de tirs assez fréquentes en cours de projet (absence de cahier des charges très précis), on arrive à des temps de production efficaces plutôt réduits. C'est pourquoi en général, vous aurez sans doute droit à un cahier des charges approximatif et une version "sortie de la boîte" d'un programme pour ce prix.

A ma connaissance pour des articles longs tu as le choix entre les type BLOB, text, varchar(Max) et XML. Selon les systèmes de bdd ces types sont un peu différents, par exemple le type text n'est pas toujours indexable, ou n'accepte pas certaines commandes SQL. Varchar(Max) prend beaucoup de place. Perso j'utilise soit text soit XML

Le nombre de titres est effectivement le point le plus difficile à cerner. Dans toute librairie généraliste , il y a un "fond" qui ne tourne pas ou très peu, et qui constitue selon les cas un investissement voire une perte sèche. A ma connaissance ceci est valable aussi bien pour les libraires spécialisées que pour les rayons de supermarchés : Le chiffre d'affaires est malheureusement lié au nombre de titres en stock. Autrement dit pour vendre vos 200 titres les plus connus, à priori il faudrait détenir les 1300 autres plus rares. Sur Internet l'effet "rareté" est amplifié, il est même possible que vous ayez plus de chances de vendre les livres rares que ceux plus connus ! (dans l'hypothèse où il y existe un marché bien sûr) A vous de trouver le subtil équilibre, et d'arriver à vous procurer les titres les plus rares : la plus grande difficulté pour une librairie spécialisée est d'acheter, celui qui sait bien acheter vendra sans problème. Bonne réussite !

Bonjour Libraire, et bienvenue sur le Hub Vos questions s'adressent à des interlocuteurs différents : des libraires, des webmasters, des spécialistes de la comptabilité...dans ces cas là mieux vaut poster plusieurs questions dans différentes rubrique du Hub. Bon voici quand même quelques pistes : 1. A priori vous aurez à administrer votre site. Ce sera à vous de mettre à jour votre catalogue, traiter les commandes, planifier les futures versions, le faire connaître, répondre aux e-mails etc... Prévoyez une partie de votre emploi du temps en conséquence. En pratique c'est très faisable tout seul, surtout avec un stock de 200 titres. De toute manière vous aurez du mal à démarrer avec un salarié sur un aussi faible stock. D'ailleurs vous connaissez une librairie qui tourne avec 200 titres ? 3. Adressez vous directment à bshop, il est membre du Hub 4. Un client n'est pas perdu s'il trouve un intérêt réel à chercher. Si vos livres sont rares, votre catalogue ne fera pas peur à un internaute motivé. Il existe des librairies en lignes avec des dizaines de milliers de titres dans lesquelles on ne se perd pas 5. en régime micro vous ne déduisez pas la TVA donc vous achetez TTC et vous revendez de même 7. Voyez un expert comptable... Sur l'aspect synchronisation des stocks : les solutions d'interfaces entre un logiciel de gestion et un site Internet sont relativement coûteuses. Comme vous démarrez, à votre place, je demanderais au prestataire internet d'intégrer la gestion des stocks dans l'application web : vous aurez vos stocks en temps réel.

Voici un lien qui peut t'interesser, je connais bien aspaway. http://www.lesinfos.com/news46424.html

Je crois qu'il y a une petite confusion de ta part IWIT : l'exécutable d'Atos, même s'il est installé sur ton serveur, ne lui confie à gérer qu'un certificat, tout se passe sur les serveurs d'Atos / de la banque. Il n'y a pas de place pour d'autres intermédiaires techniques dans ce processus. A quoi serviraient-ils? Si tu souhaites développer une solution technique concurrente à celles citées, il te faudra bien du courage, l'aspect cryptage n'étant qu'une partie du problème; pour avoir ton premier client, il va falloir convaincre au moins une banque de travailler avec ta solution.

1.la validation : contrôle les fonctions javascript qui sont appelées dans la validation. Peut-être as-tu effacé par erreur ces fonctions; dans le doute régénère les. 2.L'envoi d'e-mail : nécessite un serveur SMTP. vois avec ton hébergeur quel le nom du serveur, puis utilise un script type jmail.

En effet c'est un peu plus clair... Pour moi le point de départ du projet c'est la logistique. Même si votre entité juridique est distincte de celle de votre fournisseur, vous devez tenir compte de l'emplacement physique des stocks, et donc, des informations venant de la gestion de votre fournisseur. Imaginons que vos stocks soient ceux d'un grossite qui veut ouvrir un canal de diffusion B2C (simple hypothèse). Dans ce cas les stocks physiques sont dans les entrepôts du grossiste. Leur disponibilité est un facteur clé de succès (si le grossite réserve 100% d'un article, il ne n'en reste aucun pour la vente aux particuliers sur votre site) : donc les niveaux de stocks doivent être mis à jour très souvent à partir de l'informatique du grossiste, idéalement en temps réel. Il va donc falloir développer une passerelle entre le catalogue de produits du fournisseur (avec l'info stock) et votre site, pour pouvoir récupérer toutes ces infos. L'EDI est une possibilité, mais ce n'est indispensable que si votre partenaire logistique l'exige. Autrement votre budget risque d'y passer. Un web service est moins coûteux et complexe à mettre en oeuvre. Pour ce qui est de la technologie, il y a 2 grandes approches : Partir du front office (par exemple OSC) et chercher un prestataire qui a travaillé le côté backoffice (plutôt vers 20 K), ou bien partir d'un back office costaud et évolutif (adonix, navision, etc...) et trouver un prestataire qui a déjà développé un front-office sérieux (plutôt vers 50 K) Dans ce dernier cas, compte tenu du budget la partie marketing sera peut être sacrifiée et ce serait dommage... Consultez déjà le prestataire de votre fournisseur, peut-être a-t-il une solution ? Excellente réussite.

Bonjour Alex01 et bienvenue sur le Hub, La réponse est très différente selon que tu as déjà une entreprise avec une structure informatique existante ou si du démarres de zéro. Par exemple, tu parles de Back Office : donc le front office est déjà développé ? Si tu démarres de zéro, à moins d'avoir un très gros budget, oublie l'idée d'un back office ambitieux, fais une boutique standard : tu referas tout dans 6 mois si ça décolle. Pour le poste de dépense "back-office", le volume des ventes que tu indiques n'a pas d'importance : c'est le front office qui supporte la charge, le back-office ne concerne que peu d'utilisateurs. Le point "Logistique" que tu évoques est en revanche prépondérant : si tu disposes déjà d'une informatique pour le traitement ou l'expédition des commandes, il faut qu'elle soit connectée au site de back-office. Voilà une première contrainte très forte sur ta solution globale. Ton prestataire doit être capable d'interfacer ton informatique existante : le front office + la logistique; le back-office étant entre les deux, ça peut être compliqué voire irréalisable...seul un audit peut le dire. L'autre contrainte : les fonctionnalités attendues du back-office : gestion des commandes, des stocks, bons de livraison, facturation, règlements, relances, suivi de la relation client, newsletter, interfaces comptables etc... Rédige un cahier des charges en essayant de préciser au maximum ces contraintes : en informatique, tout est possible, mais les heures de développement coûtent très cher. Ensuite, le poste qu'il ne faut pas négliger c'est la conduite du changement dans ton entreprise : revoir les procédures de gestion, reprendre les données sur le nouveau système, la formation des utilisateurs, etc... Bref si ton entreprise existe déjà, c'est un vaste projet, complexe, qu'il faut financer ... <edit> +1 pour l'avis d'Arlette sur bshop</edit>

Bonjour Velvounet et bienvenue sur le Hub Ta question est un peu étrange. Qu'est ce qui ne marche pas au juste ? Tu décris un processus de login qui n'a normalement rien à voir avec des problèmes d'affichage IE/firefox. L'aspect sécurité n'est pas à priori lié aux problèmes d'affichage non plus.

On peut taper son code dans notepad, ou dans des éditeurs spécialisés comme XML cooktop par exemple. En ce qui concerne les documents électroniques, XML est issu de SGML qui était fait pour traiter des documents, d'où sa bonne adéquation dans ce type de projet. Un document XML est structuré hiérarchiquement (un élément peut avoir des noeuds enfants qui eux aussi peuvent avoir des descendants), ce qui permet par exemple d'organiser des documents en titres / sous titres, et chaque noeud peut avoir des propriétés ce qui peut permettre par exemple, une indexation. Au niveau du traitement et des sorties, tout est prévu avec XSL et plu particulièrement XSL FO pour les documents sous toutes leurs forme, écran papier audio...

De mon point de vue un projet logiciel n'est jamais terminé et ça change tout le temps, au gré des clients et des opportunités. AMHA La question "à quoi ressemblera mon logiciel lorsqu'il sera terminé ? " est un peu un mirage. Le plus important est peut-être de ne pas développer de modules inutiles compte tenu de ta clientèle probable, de blinder tes modules existants (pour une appli web pas trop compliquée, le zéro bug est tout à fait possible) et surtout...vendre tes heures !!! Tu as mes encouragements.

Mais ta question est un peu vague, un langage informatique peut servir à faire énormément de choses. XML a des points communs avec les autres langages, tels que stocker, transporter, traiter, présenter des données. Dis nous plutôt ce que tu cherches à faire, pour avoir des réponses plus concrètes.

Si tu utilises du code Open Source, ton meilleur business model est sans doute l'Open Source, voire même le seul possible selon les licences dont dépend ton soft. Si tu es sur des technos propriétaires, tu auras sans doute certains composants à payer (mais la redistribution des bases de données est généralement gratuite, contrairement à Mysql). En revanche tu n'auras pas grand monde pour te suivre sur le chemin Open Source avec ces technos là. D'un autre côté tout dépend de ce que fait ton logiciel, et de sa cible en termes de taille d'entreprise, de son mode de commercialisation. Dans l'ensemble, les petites entreprises comme les grosses gagnent leur vie sur le service et pas sur les licences, qui demandent énormément de moyens maketing - donc de ce point de vue, il n'y a pas de différence.

Oui aux USA il y a aussi netsuite.com (anciennement netledger) qui prend en charge la gestion commerciale + le CRM + le e-commerce + la comptabilité. Quand je dis "réconcilier le monde du web avec celui de l'informatique de gestion", je parle d'un ERP avec une seule et même base de données pour la gestion de documents internes + CMS web + facturation + e-commerce web + comptabilité, ou à défaut, capable d'échanger des données avec certains logiciels du marché. Vtiger est intéressant mais il manque la partie CMS web (et la gestion documentaire tout court), il n'y a pas de module e-commerce, quant à la gestion commerciale elle est déconnectée de tout système de comptabilité donc inexploitable. Au niveau des web services vtiger, il reste des progrès à réaliser pour pouvoir s'en servir "en vrai". Je l'ai implémenté une fois, mais à la fin du projet, on se demande si on aurait pas mieux fait de redévelopper ses modules intéressants comme le connecteur Outlook. Le défaut des logiciels actuels AMHA est de répondre à un besoin de fonctionnalités spécifiques (CRM ou CMS ou e-commerce ou gestion commerciale, etc...) bons pour "tous les métiers", en tout cas sur le papier. De ce fait ces logiciels ne sont pas adaptés à une approche globale pour un métier bien précis. Donc on travaille sur des projets soit disant "globaux" avec des logiciels conçus comme des appli locales : une fonction = un logiciel, l'avènement de l'Internet n'a rien changé dans l'approche des solutions par la plupart des éditeurs, et l'Open source n'a pas fait mieux. Tout au plus peut on citer Compiere, mais je n'ai pas été convaincu par le module web. Il n'y a que pour les grandes entreprises que des solutions existent, (oracle IBM SAP , etc) mais là on ne joue pas dans la même cour...