Discussion :

[VironFlo]

Bonjour à tous,

j'aimerais développer un programme de gestion pour ma société.


Pour le moment, le listing est repris dans un fichier excel mais on encode chez le client après l'intervention
avec comme information:
_ Nom et prénom
_ Adresse
_ numéro de téléphone
_ nombre d'intervention
_calcul tva et prix total.

J'aimerais pouvoir remplir les données automatiquement par rapport à la tournée de la journée. En utilisant excel comme base de donnée.

J'ai surtout développer avec unity (J'ai suivis une bachelier en conception de Jeux-vidéo) et je ne sais pas vers quelle solution m'orienter pour commencer le programme qui serait développer sur Windows?

Par la suite, j'aimerais utiliser d'autres fonctions comme l'api de google map sur une application qui serait connecté à la "station principal", et qui contiendrait quelques informations supplémentaires comme une photo, remarque.

ps: ceci est mon tout premier message, j'espère avoir été assez clair, comme ma demande est assez précise, j'ai préféré faire une nouvelle discussion.

Merci d'avancer pour le temps que vous me consacrerez,
flo

[dalfab]

Bonjour et bienvenue

Il doit exister des tas de moyens pour résoudre ton problème, mais je doute fort que le C++ soit une bonne idée pour cela. Aurais-tu commis une erreur de forum?

La conception c'est important, mais ça inclut aussi le choix du "bon" langage. Peux-être qu'ici l'utilisation directe de formules Excel pourrait suffire, avec ajout possible de quelques macros.
On peut tout à fait avoir une feuille Excel qui va chercher les informations dans un autre fichier.

[koala01]

Salut, et bienvenue sur le forum.

Je ne crois sincèrement pas que excell (qui n'est jamais qu'un tableur) soit la solution la plus adaptée à ton problème. Une (vraie !!!) base de donnée serait sans doute bien plus intéressante.

L'un dans l'autre, si l'utilisateur est unique, quelque chose d'aussi simple que SQLite pourrait sans doute faire l'affaire, mais, à termes, quelque chose de plus "centralisé", permettant à plusieurs personne de travailler en même temps pourrait s'avérer des plus utiles

Quant à l'interface graphique (et l'intération à la base de donnée), le framework Qt devrait te permettre de faire exactement ce que tu veux (y compris de faire une version de ton application pour smartphones / android )

Ceci étant dit, si tu es déjà habitué à utiilser Unity, tu auras peut-être plus facile à coder ton application en C#, car tu partirais sur un langage connu, et que C++ est quand même un langage particulièrement complexe à apprendre (même si ca rajoute une corde à ton arc)

[VironFlo]

Tout d'abord merci pour vos réponses
en faite j'ai commencé à apprendre en c++ avant de me mettre au c Sharp (même si je n'ai pas poussé très loin le c++).
J'ai répondu dans cette section car je pensais qu'il fallait que je m'oriente vers ce langage.
Je ne connais pas bien excel, mais en effet, par la suite je voudrais complexifier le programme

Il y'aura plusieurs utilisateurs, à court termes, au moins trois, mais selon la croissance de l'entreprise, il pourrait y en avoir d'autres. Peux-ton travailler dans cette optique avec SQlite?

Pour aller un peu plus loin^^ ça serait bien que la base de donnée soit sur un serveur, un ordinateur recyclé dans mon cas.

[koala01]

Tout d'abord merci pour vos réponses
en faite j'ai commencé à apprendre en c++ avant de me mettre au c Sharp (même si je n'ai pas poussé très loin le c++).
J'ai répondu dans cette section car je pensais qu'il fallait que je m'oriente vers ce langage.

Pourquoi crois tu devoir t'orienter vers ce langage en particulier

Après tout, ce n'est pas comme si chaque demi seconde passée à attendre coutait des vies

Je ne connais pas bien excel, mais en effet, par la suite je voudrais complexifier le programme

Donc, il faut d'office oublier excel pour ces deux raisons

Il y'aura plusieurs utilisateurs, à court termes, au moins trois, mais selon la croissance de l'entreprise, il pourrait y en avoir d'autres. Peux-ton travailler dans cette optique avec SQlite?

SQLite pourrait faire partie de la solution pour le cas où les utilisateurs n'auraient (temporairement) pas accès au serveur sur lequel serait la base de donnée centralisée (quand il sont au fin fond de la brousse ou chez le client, par exemple ) car cela permettrait de sauvegarder les informations "en attente de synchronisation", mais cela pourrait compliquer pas mal les choses, pour, justement, arriver à synchroniser ces données.

Mais, de fait, comme on l'a déjà dit tous les deux, quelque chose de plus centralisé serait surement préférable.

Par chance, Qt fournit "tout ce qu'il faut" pour travailler avec des bases de données

• MySQL / MariaDB
• PosGreSQL
• MsSQL
• Oracle
• IBM DB2

Comme tu peux le voir, il y en a pour tous les gouts et pour toutes les bourses

L'idéal, ce serait de s'assurer que l'utilisateur ait toujours un accès au serveur (avec la 4G et autres technologies, il devient de plus en plus facile de garantir ce genre d'accès )

Pour aller un peu plus loin^^ ça serait bien que la base de donnée soit sur un serveur, un ordinateur recyclé dans mon cas.

Et je présume que tu aimerais autant, dans un premier temps du moins, faire l'économie d'une licence pour l'OS et pour le serveur de base de données que tu installera dessus, me trompes-je

Je verrais bien une installation de type "serveur" minimale à base de debian (ou autre linux), à base de MariaDB (la version complètement libre de MySQL ou de PostGreSQL pour commencer

Après, il faut garder en mémoire que ta base de données va représenter l'âme et le sang de ton entreprise : si tu la perd, tu perd toute l'histoire de ton entreprise, et tu risques d'être fameusement dans le caca à la fin de l'année

Si je comprend le souhait de recycler un vieux PC, je me sens obligé de te mettre en garde sur l'absolue nécessité d'avoir des sauvegardes régulières et de protéger ces données presque mieux que la manière dont tu protège ce qu'il y a (ou pas...) entre tes jambes

Et ce sera d'autant plus vrai si ton serveur est connecté à internet, ne serait ce que pour permettre aux utilisateurs itinérants de travailler, si bien que, alors que je plaidais plus haut pour essayer de garantir l'accès au serveur en itinérance, l'aspect "sécuritaire" de la chose plaiderait sans doute pour que ce serveur soit au pire dans une zone démilitarisée pour éviter que "n'importe qui" n'aille y foutre le bordel

A moins, bien sur, que tu ne connaisse un spécialiste en sécurité qui puisse faire en sorte de t'aider à "blinder les accès au serveur"

Tout cela pour dire qu'il y a des solutions qui existent, mais que certains choix doivent être fait avant de pouvoir s'orienter vers l'une ou vers l'autre

On est sans doute d'accord pour dire que la solution passera par une base de données (quoi que, avec NoSQL, on pourrait aussi arriver à quelque chose de pas mal ) mais, pour le reste, il s'agira surement d'avoir bien réfléchi à la structure de ton entreprise et à la place que prendra ton serveur dans celle-ci avant de te décider

[chrtophe]

Comme c'est quand-même relativement orienté bureautique, Access serait un bon candidat. Tu pourras envisager une base autonome quand tu sera en déplacement et qui se synchronise avec la base principale au bureau : ce sera le point de difficulté.

Mais je dirais que tout dépend de la volumétrie. Mais vu la demande, je suppose qu'elle est faible.

[koala01]

Comme c'est quand-même relativement orienté bureautique, Access serait un bon candidat.

Oui, mais, access n'est pas un serveur de base de données relationnelle... c'est un système très similaire à SQLite (avec toute la partie graphique qui va bien, je te l'accorde), d'avantage prévu pour une utilisation locale; on pourrait presque dire "embarquée dans l'application"

Dés qu'il s'agit d' avoir plusieurs utilisateurs qui travaillent (à partir de machines différentes) sur la même base de données, les problème de synchronisation pointent le bout du nez

Sans oublier un point capital : access est "windows only". On pourrait croire que ce n'est pas un problème, mais je n'en mettrais pas ma main au feu !

Tu pourras envisager une base autonome quand tu sera en déplacement et qui se synchronise avec la base principale au bureau : ce sera le point de difficulté.

Si tu pars sur access, le problème de synchronisation se posera même si les deux utilisateurs travaillent dans la même pièce!

Il sera beaucoup plus facile à résoudre -- que ce soit "dans les bureaux" ou en itinérant, si la base de données globale prend la forme d'un serveur, même si ce serveur n'est pas accessible par internet

Mais je dirais que tout dépend de la volumétrie.

Tout à fait

Mais vu la demande, je suppose qu'elle est faible.

Comme mon vénéré père dit toujours :

Il faut laisser croire les béguines, elles sont spécialistes et payées pour!

Autrement dit : méfie toi des a priori qui peuvent n'être valables que sur des très courtes périodes. Le simple fait que l'on parle dés le départ d'avoir trois utilisateurs plaide déjà en faveur d'une volumétrie que l'on pourrait ad minima qualifier de moyenne, même s'il n'y a qu'une seule entrée par personne et par jour, pour la simple et bonne raison que, à la fin de la journée, les trois utilisateurs devront travailler sur la base de donnée "en même temps" (ou, du moins, on doit partir du principe que ce sera le cas).

Or, cette situation se présentera, selon les propres termes de @VironFlo "à court termes", ce qui veut dire "assez rapidement", et ca risque encore de n'être qu'un début

Il serait dommage de se limiter volontairement en se basant sur une volumétrie faible et de devoir transférer l'ensemble des données déjà introduite sur un système "plus robuste" uniquement parce qu'on se rend compte qu'il devient impossible de travailler à quatre sur la base de données créées, et ce, même si on a -- au moins -- l'avantage d'avoir une structure "toute prête".

EDIT: D'autant plus que rien ne nous interdit (dés que l'on est en mesure de garantir l'accès à internet de la personne itinérante) d'envisager la création d'un "client léger" basé sur ou utilisant un navigateur internet pour y accéder.

Or, l'intégration d'une base de donnée access à un serveur ne peut (ne pouvait cela a peut-être changé ) se faire qu'ave ISS et, pour l'avoir fait à l'époque (il y a près de vingt ans de cela), je peux te garantir que ce n'est pas forcément le système de base de données le plus facile à intégrer

[chrtophe]

Dés qu'il s'agit d'avoir plusieurs utilisateurs qui travaillent (à partir de machines différentes) sur la même base de données, les problème de synchronisation pointent le bout du nez

Cela ne posera pas de problème en mettant la base sur un partage réseau, dans ce cas plusieurs utilisateurs peuvent accéder à la base simultanément, la limite étant le verrou de la fiche en cours (sinon il faut un serveur SQL, Access pouvant se connecter dessus). Il sera même possible d'envisager de la synchro d'une version offiline emmené chez le client, il me semble qu'un membre a fait un tuto là-dessus.

Pour la volumétrie, vu qu'actuellement c'est Excel qui est utilisé, je pense qu'Access conviendra, et ça reste facile d'accès.

Bien sûr Qt conviendra aussi mais demandera beaucoup plus de travail que faire une petite base Access.

La demande est d’utiliser Excel comme base de données, je conseilles plutôt Access, Et même sous Excel, il pourrait faire un onglet pour l'affichage des devis, ce que semble être ce qu'il veut faire en plus d'ajouter un module d'accès Google Map.

Par la suite, j'aimerais utiliser d'autres fonctions comme l'api de google map sur une application qui serait connecté à la "station principal", et qui contiendrait quelques informations supplémentaires comme une photo, remarque.

Tu pourras insérer des photos dans Access dans un champ pièce jointe si il n'y en a pas trop, en général dans une base de données, on oinsère plutôt un lien vers un fichier externe, mais pour une volumétrie faible, ça peut s'envisager.

[kevin254kl]

Salut,

+1 Pour Access, en effet avec un partage réseau de la base et si y'a pas une forte volumétrie je recommande aussi. De plus la mise en place est vraiment rapide avec la génération des formulaires ...

[koala01]

Cela ne posera pas de problème en mettant la base sur un partage réseau,

Salut,

+1 Pour Access, en effet avec un partage réseau de la base et si y'a pas une forte volumétrie je recommande aussi.

Je comprend votre point de vue, mais je n'y adhère absolument pas, ne serait-ce que pace que

1-

dans ce cas plusieurs utilisateurs peuvent accéder à la base simultanément, la limite étant le verrou de la fiche en cours

Ce qui est déjà en soi une limite importante, quelle que soit la volumétrie envisagée.

Or, si je ne pouvais faire valoir qu'un seul avantage au C++, c'est qu'il nous oblige très rapidement à nous rendre compte que nous ne sommes pas au pays des bisounours, et que si quelque chose peut, la loi de l'emmerdement maximum fait que nous devons partir du principe que ca foirera forcément à un moment ou un autre (et de préférence au pire moment qui soit).

Si le verrou sur le fichier risque de poser problème, il faut donc partir du principe qu'il posera forcément problème, et plutôt deux fois qu'une

2-

(sinon il faut un serveur SQL, Access pouvant se connecter dessus).

Que ce soit l'un ou l'autre, cela implique de travailler avec windows (même si c'est sur une machine virtuelle tournant sous linux), ce qui pose un sérieux problème dans l'optique affichée par @VironFlo d'utiliser

un ordinateur recyclé dans mon cas

3-

De plus la mise en place est vraiment rapide avec la génération des formulaires ...

La mise en place d'un vrai serveur de gestion de base de données (qu'elle qu'il soit) et d'une base de données n'est pas moins rapide qu'avec access ...

Et, s'il ne reste que la génération de formulaire comme avantage, le faire avec Qt et son designer ne sera pas plus compliquée

Il sera même possible d'envisager de la synchro d'une version offiline emmené chez le client, il me semble qu'un membre a fait un tuto là-dessus.

Tout comme pour l'ensemble des SGBDR dont j'ai parlé

Pour la volumétrie, vu qu'actuellement c'est Excel qui est utilisé, je pense qu'Access conviendra, et ça reste facile d'accès.

Je te rapporte au premier point que j'ai exposé lors de cette intervention

Bien sûr Qt conviendra aussi mais demandera beaucoup plus de travail que faire une petite base Access.

Oh, je n'en serais pas forcément aussi sur

Bien sur, il y aurait quelques requêtes à écrire et à tester, mais il faudrait aussi le faire sous access. Entre Qt designer et le QML, (ou même python, si on se sent plus à l'aise avec ce langage), le travail ne devrait pas être tellement plus dur

La demande est d’utiliser Excel comme base de données, je conseilles plutôt Access,

Si ce n'est que, de mon point de vue du moins, Excel présente exactement les mêmes problèmes que Access

Et même sous Excel, il pourrait faire un onglet pour l'affichage des devis,

Ce qui ne manquera pas de poser de sérieux problèmes (de synchronisation, entre autre).

Or, la base de données devient rapidement le coeur même de l'entreprise : peu importe que les dirigeants prennent des bonnes décision (... ou non), peu importe que les employés soient (... ou non) motivés pour faire évoluer favorablement l'entreprise : si la base de données plante, c'est tout le reste qui s'effondre, faute de fondations solides.

Et je ne parle même pas des obligations légales en termes d'archives et de protection de la vie privée (qui pointent systématiquement le bout de leur nez dés qu'on parle de base de données)...

On peut décider de simplifier beaucoup de choses (dont la vie des employés, en leur évitant d'avoir à faire trente six manipulations alors que deux suffisent), mais la base de données, elle, elle doit être en béton armé pour satisfaire à toutes les exigences qu'elle implique

De mon point de vue, il n'y a rien à faire : Access est beaucoup trop simple, pas assez blindée sur beaucoup trop de points que pour être considéré comme une alternative viable pour la gestion d'une entreprise

ce que semble être ce qu'il veut faire en plus d'ajouter un module d'accès Google Map.

Qui peut se rajouter très facilement à peu près n'importe où, y compris sur un client léger

Tu pourras insérer des photos dans Access dans un champ pièce jointe si il n'y en a pas trop,

Comme dans n'importe quelle base de données, y compris SQLite

en général dans une base de données, on insère plutôt un lien vers un fichier externe, mais pour une volumétrie faible, ça peut s'envisager.

Encore une fois, que feras tu quand tu remarqueras que ta base de données access ne suffit plus tu perdra six mois, un an, plus peut-être, à redévelopper pour une autre base de données exactement la même chose que ce que tu as fait pour access

Encore une fois, j'en reviens au premier point de cette intervention (décidément, j'ai l'impression de tourner en rond, pour cette intervention )

EDIT : Et parce que je revendique mon point de vue, ne vous posez pas la question de savoir qui a émis les votes négatifs : C'est moi, car je trouve que vos arguments ne sont absolument pas convaincants

[chrtophe]

La mise en place d'un vrai serveur de gestion de base de données (qu'elle qu'il soit) et d'une base de données n'est pas moins rapide qu'avec access

mais reste plus complexe.

Que ce soit l'un ou l'autre, cela implique de travailler avec windows (même si c'est sur une machine virtuelle tournant sous linux), ce qui pose un sérieux problème dans l'optique affichée par @VironFlo d'utiliser

Sauf que l'utilisation d'Excel signifie l'utilisation de Windows ou Mac et pas Linux. Pas d'Access sous Mac, mais Excel pourrait suffire comme précisé, et fort probable que l'utilisateur soit sous Windows (mais ça seul lui peut le confirmer).

Il faut être pragmatique, qu'est ce qui est le plus accessible à monsieur tout le monde pour une petite appli bureautique ? utiliser Excel/Access ou Qt ?

Nous sommes dans les forums C, mais il ne me parait pas aberrent de réorienter le demandeur vers une solution moins lourde.

EDIT : Et parce que je revendique mon point de vue, ne vous posez pas la question de savoir qui a émis les votes négatifs : C'est moi, car je trouve que vos arguments ne sont absolument pas convaincants

C'est ton droit, je ne suis pas d'accord avec toi mais ne t'ai pas mis de vote négatif, mais peu importe. Le demandeur a deux points points de vue opposés, il fera son choix.

[VironFlo]

Vous avez été très complet sur les réponses, ça fait plaisir

Tout d'abord, par rapport à l'ordinateur recyclé :
plus j'y réfléchis, plus je trouve cela contraignant... surtout que ma connexion actuelle n'est pas terrible (voir inexistante en upload), je ne préfère pas me tirer dans le pied (j'ai déjà eu la blague avec la perte de gros fichiers auparavant, doux souvenir ).
En ce qui concerne l'orientation du projet vers Acess, ou sql:
je pense plus sur sql :
L'objectif premier est de réduire le travail des utilisateurs qui sont en déplacement(visite clientèle) et d'éviter les erreurs de saisies manuels mais par la suite, les fonctionnalités auxquels je pense risque d'être une barrière sur Acess.


Il faut que se soit facile d'utilisation pour les utilisateurs débutants en informatique en général.

Il sera même possible d'envisager de la synchro d'une version offline emmené chez le client, il me semble qu'un membre a fait un tuto là-dessus.

J'aimerais en effet avoir une version offline, avec un bouton pour rafraîchir par exemple.

Pour ce qui est de l'utilisation d'excel, ce n'est pas une obligation, je me suis un peu mal exprimé, actuellement la base de donnée est dessus, c'est pas très volumineux, néanmoins, il y'a déjà quelques 1600 clients, et 20% pourrait contenir une photo dans les informations.

Je ne me rends pas bien compte du temps que cela va prendre de développer un tel outil, avec un investissement de temps qui n'est pas extensible , disons environs maximum 10 heures par semaines.

[koala01]

mais reste plus complexe.

Ah, ca demande de savoir ce que l'on fait au moment d'accorder les droits d'accès, en effet. Mais pour quel bénéfice en thermes de sécurité !

Sauf que l'utilisation d'Excel signifie l'utilisation de Windows ou Mac et pas Linux.

Mais si on part sur cette optique, n'importe quel tableur fera l'affaire

Pas d'Access sous Mac, mais Excel pourrait suffire comme précisé,

Et c'est bien, avec le verrou posé lorsque le fichier est utilisé, l'un des problèmes majeurs des outils de microsoft (que l'on parle d'un tableur ou d'un(e) (SG)BDR: les outils de microsoft ne fonctionnent que sur les OS de chez microsoft.

Or, si les gens sont -- souvent -- plus habitués à utiliser les programmes de microsoft (et encore: il semblerrait que ce soit de moins en moins le cas), l'utilisation d'autres produits équivalents (je pense à issus de la suite open office, entre autres) n'en est pas forcément plus compliquée, et l'habitude vient assez facilement.

Dés lors, pourquoi devrait donc proposer par défaut des programmes pour lesquels les rares avantages sont largement contrebalancés par leurs (nombreux) défaut plutôt de des programmes qui permettent d'ouvrir toute une série de pistes qui ont de très fortes chances d'être suivie à termes

et fort probable que l'utilisateur soit sous Windows (mais ça seul lui peut le confirmer).

Tu sais sans doute aussi bien que moi qu'il y a de plus en plus de gens qui abandonnent windows au profit de MacOS, linux ou même android

Encore une fois, par pitié, évitons de partir sur des hypothèses dont l'obsolescence pour ainsi dire prévisible nous obligera à faire deux fois le travail à cause des restrictions qu'elles posent. Car, a priori, aucun dirigeant d'entreprise n'accepte de gaité de coeur le fait qu'un développeur vienne lui dire qu'il faut ... perdre du temps à redévelopper quelque chose d'existant "simplement" parce que "la situation actuelle impose certaines limites".

Il faut être pragmatique, qu'est ce qui est le plus accessible à monsieur tout le monde pour une petite appli bureautique ? utiliser Excel/Access ou Qt ?

Pour l'utilisateur, cela ne changera absolument rien

Pour le développeur de la solution, celui dont le rôle est d'empêcher l'utilisateur de faire des conneries alors que l'utilisateur est un imbécile distrait qui n'attend que l'occasion d'en faire, l'utilisation de Qt (ou de n'importe quel autre framework d'IHM) associé à un vrai langage de programmation sera a priori bien plus efficace pour lui permettre d'atteindre son objectif

Nous sommes dans les forums C,

Et plus précisément sur le forum C++

mais il ne me parait pas aberrent de réorienter le demandeur vers une solution moins lourde.

Sur ce point, nous sommes bel et bien d'accord

Seulement les solutions "moins lourdes" (pour l'utilisateur, s'entend), comme le fait de permettre à l'utilisateur de faire son taf au travers de n'importe quel navigateur internet correspondent rarement aux solutions "simplistes" que tu préconise telles que "créer une base access" ou "créer un fichier excel" vite fait, et basta.

Ce genre de solution peut effectivement s'avérer utile, pour permettre à une personne de gérer sa bibliothèque personnelle, les activités des enfants, sa liste de courses, ou même les résultats au tournoi (officieux) de 421 ou de pêche organisé par l'association des parents. Mais, dés qu'il s'agit de gérer les résultats d'une entreprise, avec toutes les obligations que cela peut imposer d'un point de vue légal, ca devient largement insuffisant!

Le demandeur a deux points points de vue opposés, il fera son choix.

C'est peut-être tout ce qui importe réellement au final

[koala01]

Je ne me rends pas bien compte du temps que cela va prendre de développer un tel outil, avec un investissement de temps qui n'est pas extensible , disons environs maximum 10 heures par semaines.

Malheureusement, tout ce que tu pourra faire avec un tel crédit de temps de développement ne sera que du pur bricolage (même si cela plaide en faveur de l'utilisation simple d'une base de données access), avec une conséquence prévisible: tôt ou tard, cela te claquera dans les pattes

Le développement d'une solution pérenne et capable de suivre les évolutions de ton entreprise se compte sans doute en plusieurs mois avec une (ou plusieurs) personne(s) qui se consacrent "exclusivement" à cette tâche