Hello,
 
Je bosse dans une boîte de localisation, on a pas mal de suivis à faire (achats/ventes de traduction en particulier) et le classique Excel de suivi qui existait à mon arrivée montre ses limites. On a pas de dev en interne, et vu la spécificité, y'a pas 40 000 solutions existantes. Ca fait un moment que j'ai pas fait de trucs un poil conséquent en dev (7 ans...), mais je suis pas complètement rouillé non plus, donc vais m'y coller. En plus j'ai plutôt envie de m'actualiser un peu, donc ça fait un challenge intéressant
 
Le besoin :
- Suivi d'achats/ventes de trad (des mots, des tarifs fournisseurs ou clients...)
- Suivi facturation (sortir des bons de commandes pdf, des xls de rapport, remplir des devis pour clients...)
- Au max une grosse dizaine d'utilisateurs simultanés
- Certaines parties (tables projets, clients...) seraient partagés avec une deuxième appli qui ferait suite, pour gérer la partie enregistrements (gérer des scripts excel, des fichiers, le suivi budgétaire...) plus grosse en terme de volume (on traite des millions de mots par an)
- pas cher (on m'a fait comprendre que gratuit ça pouvait être bien aussi )
 
Mon idée :
- vb.net (je pars pas de rien, j'ai déjà fait un peu de vb et beaucoup de vba, et ça m'a l'air plutôt friendly pour manipuler des fichiers xls)  
- serveur mysql (je connais, c'est gratuit, les connecteurs .net sont dispos)
 
Questions :
- une édition express, ça suffit pour ce genre de choses ?
- y'a mieux comme solution avec ces paramètres ?
- on me demande d'estimer à la louche le temps de travail pour faire ça, 3-400h en comptant le tâtonnement du début ??  
 
Merci !

Avant de te lancer dans le dév et vue qu'il n'y a pas trop de compétences en interne, vaudrait mieux se tourner vers un soft sous licence GPL
 
Pourquoi pas un ERP : http://www.commentcamarche.net/faq [...] icence-gpl
 
En appli web, je pense que ce serait encore mieux (à base de php par ex), ça facilite les MAJ.

Un ERP on en a déjà un, et on y voit toutes les limitations d'un soft qui n'est pas conçu pour nous (même si on a du support direct du développeur). Le suivi prend beaucoup de temps et l'idée c'est d'en gagner
 
Appli web, ouais pourquoi pas dans l'absolu, mais y'aura pas mal de fonctionnalités qui seront galères à reproduire (typiquement copier/coller entre l'appli et des tableaux Excel par exemple). Et en serverside, je sais pas ce que ça donne de manipuler des fichiers xls  

Ne confond pas outil de suivi et outil de reporting. Dans l'outil de suivi, tu peux très bien y mettre en pièces jointes des fichiers (qui permettront donc une mise en forme plus poussée qu'un page web, encore que, quand tu vois ce qu'on fait avec google doc). L'outil de suivi doit simplement permettre d'enregistrer des fiches et de retrouver l'info (dans ton cas, des transactions financières).
 
Pour du reporting, y'a des outils spécialisés, y compris en GPL, style Pentaho (version libre de business object), un ETL qui permet de se connecter à n'importe quelle BD, d'en extraire des données, créer des indicateurs qui seront ensuite mis dans des rapports (pdf, word...).

Je confonds pas, ils veulent un truc unique, pas de combinaison d'outils
J'ai regardé un peu Pentaho, ça a l'air effectivement très puissant. Le truc qui me gêne dans ce genre d'outils, c'est de ne pas savoir (puisque je pars de zéro) à l'avance si je vais pouvoir gérer les multiples exceptions que je vais devoir appliquer sans trop me prendre la tête. Et ça je le saurais pas avant d'y avoir passé du temps dessus, alors que si je code moi-même, je sais que je pourrais le faire... Mais ouais, ça a l'air sympa, tu me mets quand même le doute (tant mieux l'idée de mon post de départ c'est aussi de me faire réfléchir à des choses auxquelles j'aurais pas pensé moi même...)

D'expérience, les gens pensent très souvent que leur cas est unique ou qu'ils ne peuvent faire comme les autres. Dans la pratique, en prenant du recul et en modélisant de manière plus abstraite/générique son cas/besoin, on s'aperçoit vite qu'en fait, on est dans le cas général à 80%. Pour les 20% qui restent, soit du développement spécifique, soit l'outil dispose d'une communauté active et tu trouveras peut-être une ou plusieurs extensions qui couvrent le reste de tes besoins ou quasiment (voire même faire un peu  de dév sur ces extensions).
 
Edit : donc, mon conseil, trouver un soft en GPL de type web qui est assez évolutif, par ex, qui propose un système de plugins/extensions et un système d'ajout de champs personnalisés dans les fiches qu'il propose de base. Avec ça, tu devrais t'en sortir.
Le tout, c'est de trouver le nom du type de soft qu'il te faut (peut-être de type CRM).
 
http://fr.wikipedia.org/wiki/Liste_de_logiciels_libres

Oui, tout à fait  
 
Après, c'est soit je m'occupe de ça pendant l'hiver, soit ils me filent un portail web à faire, et j'ai pas envie de faire du web...  (ouais, c'est un peu con comme motivation, mais si je fais plus de dev officiellement, c'est aussi pour pouvoir choisir les petits trucs que je vais faire )
 
J'vais profiter de mes 15 heures de train prévues pendant les vacances pour voir ce qui serait faisable ou pas avec de l'existant, mais je pars pas convaincu (les 20% qui restent, c'est assez tordu/illogique parfois...)

Un changement d'outil, c'est aussi l'occasion de remettre à plat les processus/méthodologies de travail Y'a peut-être des cas tordus qui n'ont plus lieu d'être ou qui pourraient être traités différemment...

Oui ça c'est prévu, mon ennemi déclaré c'est la compta, mais une comptable de 50 ans avec 15 ans de boite, c'est pas facile à faire bouger  
 
Ce qui est encore moins facile à faire bouger ce sont les clients avec leurs process tous plus différents et étranges les uns que les autres

Tu pourrais pas décrire beaucoup plus précisément ton besoin, svp? En MP, si ça te gêne de le faire ici.
 
Perso, j'ai conduit plusieurs changements avec un certain succès dans plusieurs services d'une grosse administration, tout à base de produits GPL. Ce que j'en ai retenu, c'est que pour faire adhérer les gens, c'est de leur montrer ce que la nouvelle solution/organisation/méthodo va leur apporter et améliorer leur quotidien (gain de temps et/ou de sous). Des fois, ça peut prendre du temps, faut être patient (une de mes conduites du changement a pris plus de 3 ans pour convaincre une majorité : 2 personnes convaincues au début, entre 12 et 140 aujourd'hui )

Je vais essayer
 
En entrée, tu as la demande de prestation. Soit venant d'un client, soit en interne (venant aussi d'un client, mais c'est plus le même service). Une quinzaine de types de prestations :
- qui se comptent en mots, acheté en €\mot, et vendu en €\mot (trad...)  
- qui se comptent en unité minute, acheté en €\minute, vendu en €\minute, la minute se calculant à partir du nombre de mots. Le ratio mot\minute n'est pas forcément le même entre l'achat et la vente, et dépend du sous-type de tâche et du client. Ça peut aussi être négocié pour un projet en particulier.  
- qui se comptent en unité heure, acheté à l'heure, vendu à l'heure, ou au mot...
- au forfait, sur une tâche comptée normalement en mots ou unité temps.
 
On a des tarifs de base en vente et en achat pour chaque presta, mais qui varient suivant le client ou le fournisseur, ou suivant une négo sur un projet.  
 
Pour chaque demande, on a un mois de facturation (qui n'est pas forcément le même que le mois de la demande). Chaque demande est contenu dans un devis (une ou plusieurs demande par devis), généré avant ou après l'arrivée de la demande.  On reçoit alors un bon de commande du client (qui peut contenir un ou plusieurs devis, mais pas forcément intégralement. Ex : Devis "aa", contient deux prestas a1 et a2, devis "bb", contient une presta "b1", on peut recevoir un bon de commande contenant a1 et b1). Pour l'instant, pour certains gros clients, vu le nombre de bons de commandes, j'ai fait une lecture automatique de PDF pour faire un rapprochement automatique avec le suivi. Il faut alors émettre une pré-facturation à destination du service compta. Les modèles de préfac, bon de commandes ou devis varient bien sûr en fonction du client
 
Pour chaque demande, on a une ou plusieurs demandes faites à des fournisseurs, le fournisseur peut être en interne. En fin de mois, il faut émettre un bon de commande à chaque fournisseur pour chaque projet, dont le format varie en fonction du statut du fournisseur (agessa, urssaf, étranger...). Un rapprochement est fait à réception de la facture du fournisseur.  
 
Un projet, c'est un ou plusieurs clients, avec un ou plusieurs sous-partie (batch). La presta, c'est une tâche, une sous-tâche, un indicateur d'urgence et d'état de la demande (travail de nuit par exemple).  
 
En reporting, c'est relativement simple pour l'instant (je te laisse imaginer la tête de l'Excel qui contient ça, en extraire des données c'est d'un pénible), et pour l'instant j'ai seulement automatisé un calcul de marge par client final (ah oui, y'a un client et un client final, des fois il y a des intermédiaires...), mais il faudra que je fournisse un peu plus d'indicateurs et autres KPI sur les projets, fournisseurs, presta.  
 
Le suivi sert également de base pour suivre la disponibilité des fournisseurs, mais cette dispo est trackée dans un doc à part, je voudrais lier ça automatiquement sur des bases de vélocité pour chaque tâche, et des deadlines demandées par les chefs de projets à leurs fournisseurs.  
 
Le but étant d'automatiser toutes les saisies :tarifs, choix des fournisseurs sur un projet, reporting/compta, suivi de ce qui est à faire, reste à faire, le tout en permettant aux utilisateurs d'avoir l'impression de ne pas changer ses habitudes (ex, j'ai des CDP qui abusent des couleurs pour faire des vérifs, des suivis, il faudra  que je fournisse des mécanismes de remplacement).
 
Y'a encore des petites subtilités (par ex, on a des chefs de projets, des chargés de projets et des stagiaires, et ce qui est saisi par les chargés de projet est validé par les chefs de projet tout en étant directement visible dans le suivi, ce qui est saisi par les stagiaires n'est visible qu'après vérification), mais le gros du truc c'est tout ça.  
 
 
 
 
 
 
 

Ben franchement à par un outil de type ERP (ou un truc du genre Microsoft EPM + sharepoint) pour répondre à tous ces besoins, je vois pas autre chose
 
Par contre, je maintiens que pour le reporting, faut passer par un autre outil comme pentaho, tu trouveras jamais un outil tout intégré qui fera tous les indicateurs dont t'as besoin.
 
Et vue le nb d'exigences, un dév spécifique va vous prendre un temps fou (doit bien y en avoir pour 300-400 H/j).

Bon je retrouve mon estimation sur les 3-400 heures, déjà je me suis pas planté sur ça

On va pas réinvestir dans un Erp de toute façon (et le notre ne colle vraiment pas pour ce suivi), j'vais avoir pas mal de temps cet hiver, donc why not... Au moins j'ai l'avantage de bien connaitre le problème même si je bosse pas dans ce service, ça aidera. Je vais suivre ton conseil pour le reporting et me concentrer sur le suivi

PS : merci pour la réflexion

 
J'ai pas dit 300-400 heures, mais 300-400 H/j (Homme/jour), c'est pas du tout pareil!!! Si tout ce que tu m'as décrit doit être dans cet outil, c'est ce genre de charge. 400h, ça fait environ 50j. Tu couvriras pas tous tes besoins.
 
Pour info, il existe des ERP sous licence GPL. Ca serait plus simple de repartir d'un de ces produits, t'en prend un qui propose des plugins et tu développes qq plugins pour coller à ton besoin.
 
Cela dit, vu que c'est de l'achat/vente, regardes peut-être Magento, un outil de e-commerce en GPL. Y'a une extension "logistique" assez évoluée pour environ 500 euros je crois. Tu pourrais développer qq extensions...
 
Par contre, j'en démords pas, pour le reporting, un ETL comme Pentaho... Perso, pour mon soft de help-desk en GPL, Astres (cf ma signature), rien que pour les stats, j'ai bien dû y passer 50-60j sur environ 600j de dév/doc

Ouais Ok, j'ai lu trop vite ^__^
 
Par contre, je pense vraiment pas en avoir pour autant de temps, j'avais fait un truc similaire dans mon ancienne boite (mais tout en vba sur base d'Excel partagé) et j'en avais eu pour 150-200 heures, alors que je découvrais vba (et j'avais jamais fait de vb à l'époque). Ça sera pas tout propre en 400h, et c'est sûr que je ferai pas un truc souple qui prend plus de temps à faire pour s'adapter à un max de possibilités, mais quelque chose d'assez figé, j'ai le sentiment que c'est faisable... J'ai déjà pas mal de bouts de logique réutilisables qu'il faudra juste que je passe de vba en vb, et quelques modules comme l'import de PDF que j'ai déjà sous forme de dll en vb6.  
 
Pour le reporting, oui, je te suis là-dessus, j'ai déjà un peu regardé Pentaho et tu m'as convaincu
 

Développer une appli complète web from scratch prend du temps. Bien modéliser la BD, définir les use cases, les profils/droits d'accès, définir la charte graphique et la tête des écrans, coder l'appli en respectant le pattern MVC et faire toutes les opérations CRUD, moteur(s) de recherche, coder les modules d'export (voire d'import) et d'impression, définir un système de plugin...  
 
Moi aussi, j'avais fait une petit appli sous excel qui faisait un peu le suivi des tickets comme dans Astres, en qq heures seulement. Mais la puissance d'un outil web reposant sur un BD n'est pas comparable (automatisation de tâches comme l'envoi de mails de notif, synchro de données, levée d'alerte, remonté auto d'indicateurs...).
 
Une appli de cette taille sous Excel ou vb me paraît pas viable : très difficile à maintenir, faire évoluer et je te parle même pas des perfs en multi-users

Ouais je sais pour du web from scratch, j'en ai déjà fait (à part du vba, c'est le seul truc où j'ai une vraie expérience), c'est aussi une des raisons pour laquelle je ne veux pas faire du web pour ça, j'ai commencé à jouer avec .

J'avais fait un truc en vba qui fonctionnait pas mal (avec toutes les limitations de l'outil, en particulier au niveau des perfs, surtout qu'il n'y avait pas de base derrière, juste des tableaux Excel). Quand je vois les différences de perfs entre du pur vba et du vb6 appelé par du vba (avec l'interface vba/vb6 qui pompe pas mal), je suis pas trop inquiet pour le vb par rapport au VBA toujours, et je vois pas pourquoi ça serait si lent comparé à du web

Pour les updates, ça sera certes plus compliqué qu'avec un serveur web, mais il y a pas non plus un nombre énorme de postes, et si je bosse bien sur ma solution de déploiement (je pensais faire un système de mise à jour automatique), ça devrait passer tout seul nan ?