Bonjour,
 
À combien évalueriez-vous ce genre d'appli devant être intégrée à un intranet ?
 
- L'utilisateur se connectant à son intranet se voit automatiquement connecté sur l'appli de gestion des stocks, sinon utilisation d'un profil de consultation only.
- Droits différents en fonction de l'utilisateur/groupe : consulter/lister, ajouter, modifier, retirer, sortir un produit.
- Données et actions différentes en fonction du type de produit (ex : date de péremption ou fiche de sécurité pour un produit chimique, pas d'identification unique pour des fournitures de bureau).
- Fonctions de tris (produits à commander de nouveau, produits périmés, produits sortis, etc.).
- Fonctions de recherche d'un produit : existe t-il ? est-il en stock ?
- Définir des lieux de stockage détaillés en zones.
 
Il faut pouvoir définir si l'on possède ou non un produit, si oui, le localiser et définir si on peut l'utiliser (périmé ? réservé ?). Les produits chimiques nécessitent une traçabilité individuelle et un maximum de données doivent être renseignées (n° CAS, date de péremption, pictogrammes, nom usuel, nom chimique, fournisseur, marque, n° de lot, etc.), il faut pouvoir les rechercher par nom chimique mais leur suivi doit être effectué individuellement.
Le nombre de produits en stock sera inférieur à 2000.
Le nombre d'utilisateurs sera inférieur à 100.
Écriture d'une doc.
 
Voilà approximativement sur quelle arborescence je partais : https://www.docdroid.net/QUMxvAr/gestion-des-stocks.pdf
Côté db, une table utilisateurs, une table groupes, une table de relation utilisateurs-groupes, une table générale des produits faisant la relation avec les tables complémentaires, une table complémentaire pour chaque type de produit et lieu de stockage, une table des lieux de stockage, une table des zones de stockage par lieu de stockage.
Pas de besoin particuliers pour le HTML/CSS (pas de responsive puisque l'intranet ne l'est pas).
Des remarques ? (là c'est vraiment pensé à la va-vite en une heure, histoire de donner un cadre voir si je me lance ou non)
 
 
Mon but ? Proposer un produit clé en mains à ma boîte. J'étais en congés lors des réunions, mais ils partaient sur une appli web développée par des stagiaires. On n'a personne dont son coeur de métier est le développement. J'ai peur que le résultat mette trop temps à aboutir ou ne réponde pas bien aux attentes. Quant au côté maintenabilité on oublie je suppose.
 
Si je le fais, ce sera en-dehors de mes heures de boulot, donc à voir ce que ça peut rapporter. Un produit acheté, un an de support offert dans mes heures de boulot !
Je ne proposerai pas du dév. mais un produit qu'une fois qu'il sera terminé. De mon côté ça me permet de pratiquer, donc même s'ils n'achètent pas ça m'aura servi.

De quelle évaluation parles-tu ? Nb de jours.hommes en dév ? Coût de dév ? Coût d'achat d'un logiciel existant ?
C'est clair que la solution "stagiaires", tu peux oublier à moins de tomber sur un très bon stagiaire. Même s'il produit quelque chose d'utilisable, il y a de bonnes chances que ça ne soit pas maintenable.
Si cette appli de gestion de stock est stratégique pour l'entreprise, ça peut valoir le coup de payer un prestataire pour le dév et la maintenance.
 
Sinon, plutôt que de partir de zéro, tu peux regarder l'un de ces logiciels existants en libre : https://fr.wikipedia.org/wiki/Liste [...] %A9_ou_ERP
Si ça ne fait pas tout ce que tu veux, tu pourras toujours le modifier.
 
Mais si personne n'est du métier de dév, ça me paraît chaud comme projet. Par ailleurs, si tu ne connais pas les spécs en détail, en développant dans ton coin, tu prends le risque de rater des choses et de livrer un truc non utilisable. Comme je le dis souvent à mes clients, le diable se cache dans les détails. Je peux t'assurer que des fois, avoir rater une petite chose peut remettre en cause toute l'architecture de l'appli de gestion
Spécifier et concevoir une appli, c'est environ 1/3 du projet dans on ensemble. Le codage ne représente que 20 à 30% d'un projet. Le reste, ça va être les tests et la doc.
 
A mon travail, j'ai pu voir ce que ça a donné une appli de GMAO codée par des gens peu expérimentés : ça donne une BD modélisée avec les pieds (comprendre pleins de relations ou tables, champs inutiles), une appli qui rame à mort, tellement pas évolutive et maintenable qu'après avoir attendu 4 ans qu'elle arrive, au bout de 3 ans, on parlait déjà de la remplacer !
 
Faire une appli web, c'est une bonne idée. Mais sans formation bac+5, modéliser correctement une BD de gestion de stock (ie qui respecte la forme 3NF de Codd), ça va pas être évident. Concevoir une telle appli sans travailler en étroite collaboration avec les futurs utilisateurs et le donneur d'ordre, c'est du suicide...
 
Juste une petite métrique pour bien savoir où tu mets les pieds : environ 70% des projets informatiques échouent sur au moins l'un des 3 critères : coût/temps/respect des exigences fonctionnelles d'après Wikipedia : https://fr.wikipedia.org/wiki/Project_management_office
Perso, j'avais vu d'autres études qui était plus proche de 80 à 90% d'échec.
 
En partant de zéro, par rapport à ce que tu décris, si tu n'as quasi pas d'expé en dév, je dirais que tu en auras aux alentours de 80 à 100 j.h facile. Après, tes spécs étant très haut niveau et ne sachant pas ton niveau en informatique, difficile d'être précis Sache juste que pour une telle appli, va falloir maîtriser un langage côté serveur (genre PHP, Python, Java...), le SQL, HTML/CSS/, Javascript/Ajax + un SGBD et modéliser la BD, sans compter la partie design.
Par contre, c'est sûr que ça sera très formateur
 
Renseigne-toi tout de même sur la propriété intellectuelle par rapport à tout ce que tu produits (cf ton contrat de travail). Car même si tu développes sur ton temps libre, vu que c'est en rapport direct avec ton entreprise, il se pourrait que ce que tu coderas lui appartienne de fait...

Disons que les specs ne sont pas vraiment définies, c'est pourquoi je suis inquiet... C'est néanmoins difficile de faire pire qu'à l'heure actuelle où rien n'est centralisé et à chacun sa méthode de gérer les stocks, jusqu'au classeur papier... En fin de compte, dans le projet, je suis probablement le plus proche des utilisateurs finaux les plus demandeurs (produits chimiques).

Sinon j'ai l'habitude de projets persos, mais dans ce cadre là, rien ne me force à coder "proprement".
J'ai pensé partir sur quelque chose d'existant, mais franchement l'intégration ce n'est pas mon fort, et ça me semble tout aussi compliqué vis-à-vis du petit cahier des charges que j'ai pu dessiner.

Niveau perfs, j'ai annoncé la couleur par rapport à la taille de la bdd et du nombre d'utilisateurs, faire ramer dans ces conditions ça me semble difficile (oui j'ai éliminé l'idée d'intégrer une blockchain ). Je ne suis pas expert en SGBD mais il ne me semble pas qu'un tel projet en nécessite.

Pour la propriété intellectuelle, c'est complètement hors de mes missions et hors de mon domaine de compétences donc normalement ça m'appartient.

La question portait sur le coût facturé pour un tel développement et un nombre d'heures estimé.
Pour ce qui est de passer par un pro, tout le monde (moi y compris) préfère garder les sous sous pour d'autres investissements, après faut voir le prix. Sachant que je pense qu'il y aussi beaucoup de questions sur le remplacement de l'infrastructure en place qui est trop vieille et ne sera plus maintenue, dont on connait tous la solution "temporaire" qui perdure...
Vu d'ici, je vous plains, c'est vrai qu'obtenir des budgets en informatique c'est compliqué, ça rapporte quoi ? Non mais moi je veux du concret.    

Faire ramer une appli c'est pas dur, pas besoin de mettre une blockchain. En quelques minutes, mon stagiaire avait réussi à faire passer un moteur de recherche sur des tickets (environ 120 en BD) de moins d'1 seconde à l'affichage à presque 1min ! Pareil pour une autre listing : il n'y avait que 12 enregistrements. Ca mettait environ 30s à s'afficher. Juste parce qu'il avait fait n'importe quoi dans 2 requêtes SQL.
 
Notre appli de GMAO : il doit y avoir 10 utilisateurs connectés en même temps à tout péter et environ 700000 matériels en BD. Donc vraiment pas grand chose. Ben ça rame comme pas permis. Y'a même des fois, l'appli n'arrive plus à te sortir un listing Là encore, ça vient d'une modélisation de BD naze, des requêtes SQL codées avec les pieds et le reste du code est du même niveau...
 
Pour la pérennité du produit, coder "proprement" (sachant qu'il n'y a pas qu'une façon de coder proprement), ça coûte pas plus cher et ne prend pas forcément plus de temps. Ma définition personnelle de coder proprement :
- séparer le code relatif à l'accès aux données (le plus souvent, SGBD) et à leur manipulation
- séparer le code relatif à l'affichage
- séparer le code relatif à la gestion des vues et traitement des données. Bref, faire du MVC ou un truc qui s'y rapproche
- chaque fichier doit avoir en commentaire à quoi il sert et l'historique des MAJ. Dans le cas de fichiers type "librairie de fonctions", chaque fonction doit avoir en commentaire à quoi sert la fonction, ses paramètres d'entrée (avec leur éventuelle plage de valeurs et format) et le résultat en sortie.
- une doc à jour. Au moins les specs (avec le MCD de la BD) et le Manuel d'exploitation. Et si possible le manuel utilisateur.
- Pour automatiser les tests unitaires, d'intégration voire de validation, tu peux faire du développement piloter par les tests.
 
Si t'es proche des utilisateurs finaux, ça peut être un atout si tu fais le dév toi-même : y'aura moins de "perte en ligne" dans la transmission des besoins et moins de risque de mauvaise interprétation.
 
Pour le coût par un pro, si mon estimation de 100 j.h est correcte, ça devrait tourner entre 35K€ et 50K€ HT je pense. Oui, obtenir des budgets, c'est compliqué mais il faut voir le ROI. Combien ça vous coûte de bosser n'importe comment ? Avec une bonne appli, quel serait le temps gagné estimé ? Avec mon appli Astres, sur une équipe d'environ 30 ETP, on en a gagné 3. Donc on y a largement gagné Par contre, si l'appli est moisie, tu auras perdu ton temps et argent + insatisfaction des utilisateurs à qui on a expliqué que ça allait résoudre pleins de leurs pbs + continuer à bosser n'importe comment. Là, la perte sera lourde et je te dis pas la réticence à la prochaine proposition de mettre un logiciel de gestion de stocks... Car oui, un logiciel sans l'adhésion des utilisateurs, aussi bon soit-il, s'il ne répond pas à leurs besoins, c'est mort... Y'a tellement de cas où un logiciel a été conçu par la hiérarchie sans concertation avec les utilisateurs finaux qui l'ont refusé en bloc. Bref, ne sous-estime pas la phase de consolidation des besoins avec les utilisateurs. A mon sens, c'est le 1er facteur de succès d'un projet. La 2ème clé, c'est la qualité de l'équipe projet/codeurs.

Sur 700 000 entrées, en effet les risques sont plus importants. Bon après je me demande déjà si intégrer la gestion des échantillons (~ 2000/an) ne serait pas une bonne idée. Avec l'historique on passerait à fur et à mesure sur du < 25 000 entrées.
Je me note, système d'alertes par mail.
 
Mais sinon les 100 j ETP je pensais que c'était pour moi, pas pour un pro. Dans ces eaux là, on a tous des investissements avec des retours sur investissement bien plus évidents. Je partais plutôt sur du < 10 k€.
Cela me paraît énorme pour quelqu'un qui a déjà l'habitude de coder et de modéliser. Il n'y a pas tant de fonctionnalités que ça pourtant. Le plus chaud pour moi reste la gestion de l'authentification des utilisateurs, mais comme je disais, ça attrait à de l'intégration et c'est vraiment quelque chose où je n'ai que peu d'expérience.
 
Après, ce n'est pas mon métier, c'est vrai que j'ai du mal à estimer le temps pour bien commenter et faire une bonne doc. Je partais plus sur du 50 %(temps) de code, 30 % de réflexion/modélisation et 20 % dans le reste du fait d'être seul et de faire mon idée plutôt que celle du client. C'est en effet un pari, mais je pars du fait de déjà saisir les besoins et que ce sera toujours mieux qu'avant.
Sachant que dans tous les cas je vendrai au rabais, je partais plus sur du 3k€.

Honnêtement, j'ai du mal à croire que ce soit une bonne idée. Il doit y avoir une masse de solutions répondant déjà à ton besoin, et pour lesquelles tu peux avoir du support.
 
De plus, 3000€ pour derrière hériter de toutes les responsabilités si le produit ne fait pas le taf, ou le fait mal...

Je pars du fait que si la première solution c'est les stagiaires, tout ce qui est maintenance et support sont des aspects déjà absents.
Je vais quand même regarder un peu plus les solutions existantes mais ce que j'avais retenu, c'était que la plupart des solutions passent par un changement de l'infrastructure actuelle.

Un système d'authentification, ça prend que 2-3 j.h à tout péter.
Pour les 100 j.h, oui, c'était plus si tu le faisais toi. Cela dit, un pro, ne connais pas ton contexte métier : il faut donc qu'il acquière ce contexte. Il va aussi prendre sa marge et prendre une marge supplémentaire pour limiter les risques.
Au final, pour le dév + doc, il passera peut-être que 50 j.h mais avec le recueil des besoins, la prise de connaissance... on sera vite à 70 j.h en tout. Pour mon chiffrage, j'étais parti sur un TJM de 350 € HT. Or, il y a de la conduite de projet, donc un TJM de 450 voire 500 € HT. Bref, t'en aura au minimum pour 30K€ HT or support qu'il faudra payer annuellement pour le MCO et les évolutions qui ne manqueront pas d'arriver. Car oui, il y aura forcément des évols demandées par les utilisateurs. Si tu vends ton soft 3K€ sans support et sans faire les évols et si ton code n'est pas maintenable, il partira direct à la poubelle. 10 K€ pour un soft de gestion de stock en partant de rien, tu peux oublier Juste pour te donner un ordre d'idée des prix : j'ai fait du e-commerce il y a quelques années. Pour installer l'outil libre Magento + le configurer + importer le catalogue + faire un logo et une charte graphique, c'était 3 K€. Avec les 2-3 petites évols qu'on a demandé, on en a eu pour 6K€. Ca devait représenter mois de 10 j.h de boulot.
 
Mon soft Astres, ça fait 15 ans que je développe dessus avec pleins d'évols. J'ai donc de l'expérience. En métriques, j'ai toujours compter 33% pour la doc par rapport au temps passé à coder et tester/recetter. Ca a toujours été à peu près bon. Or, j'étais seul.
 
Et 700000 entrées pour un SGBD actuel, c'est rien. J'ai des tables avec plusieurs millions d'enregistrements qui répondent en 2-3s parce qu'elles sont bien construites, bien indexées et les requêtes sont écrites correctement.
 
En résumé, la solution des stagiaires, je confirme, vous pouvez oublier à moins de prendre des très bons qui codent depuis des années et qui ont l'habitude de publier leur travail sous licence libre; (ça vous permettra de voir la qualité du travail produit et si c'est suivi. En gros, des étudiants qui sont déjà meilleurs qu'un bon nb de pros.
La solution du dév par toi me paraît très risquée pour l'entreprise si tu ne t'engages pas sur le MCO.
La solution de tout développer par un pro se chiffrera au min à 30 K€, somme apparemment que tu penses que ta boîte ne voudra pas investir.
Du coup, la solution de partir d'un produit existant et de le faire modifier par un pro serait la plus simple et la moins coûteuse.
 
Pourquoi tu penses qu'une appli comme Dolibarr nécessiterait de changer d'architecture C'est quand même assez léger ce genre d'appli web...

On est d'accord pour la bdd, la demande porte sur une taille limitée qui fait qu'à moins de faire de la grosse merde ça devrait tourner sans chercher à optimiser à fond.
Ma solution est certes risquée mais toujours moins que l'option "stagiaire".
 
Pour ce qui est de Dolibarr, ça fait surement le taff, ce que je disais, c'est que ça s'inscrit dans un changement de l'infrastructure actuelle basée sur un ERP cantonné au financier (facturation, devis, salaires, etc.) et une appli web pour l'organisationnel (planning, mails, allocation ressources, etc.).
Mais comme toi, je suis plus pour la solution de revoir toute l'infrastructure logicielle, cela fait déjà quelques années que j'en entends parler malheureusement.

T'es pas obligé de tout utiliser de Dolibarr ou autre produit. Tu peux juste utiliser la partie gestion des stocks.
Ne pas se méprendre sur la modélisation de la BD : modéliser correctement, ce n'est pas faire de l'optimisation. C'est juste respecter les règles de l'art (cf forme 3NF de Codd : https://fr.wikipedia.org/wiki/Forme [...] me_normale ). L'optimisation vient ensuite, une fois l'appli en prod (modifier indexation des champs, augmenter la taille de certains buffers du SDBG, retravailler certaines requêtes SQL...).
Une BD dans une appli de gestion, ce sont les fondations. Comme pour une maison, si les fondations ne sont pas solides, c'est tout l'édifice qui se casse la figure Et je te garantis que devoir reprendre une appli de gestion quand on a dû modifier en profondeur le schéma de la BD, c'est très lourd...
 
En tout cas, une fois la specs faite (quelque soit la solution retenue, il faut bien la rédiger, elle), faites faire un devis par un pro, juste pour avoir une idée du coût (ne pas hésiter à ajouter qq K€ au prix donné car il y aura toujours des "surprises" ).