Bonjour à tous, 

Je suis en train de coder, pour mon boulot, une appli web pour remédier à la gestion anarchique de notre structure à base de fichiers DOCX/XSLX bourrés de macros ... (je vous raconte pas l'angoisse à chaque CTRL S).

Très simplement, je vais transférer toutes les données contenues dans mes XSLX en base de données MySQL, hébergée sur le serveur local de la boite, et j'interface ça en PHP/HTML, via un site type "admin panel" (DASHGUM de blacktie pour ceux qui connaissent). Globalement, le plus gros du boulot est d'épurer les données, virer les doublons et trouver comment structurer mes tables et mes relations pour que mon outil soit efficace, plus ergonomique et surtout que cette solution soit pérenne (qui n'a jamais corrompu un XSLX ?)

L'objectif est de centraliser la gestion de la boite sur cet outil, de lui faire gérer lui seul l'édition et l'archivage des documents (factures & offres au format PDF), d'apporter plus de sécurité et de rigueur dans notre façon de faire aujourd'hui, mais aussi la possibilité de faire de beaux exports et de beaux rapports très simplement. La boite étant au ralenti jusqu’à la rentrée, et profitant du calme des 5 prochaines semaines pour bosser sur ce projet, j'ai un objectif à début septembre. Si ce n'est pas finalisé, cela attendra janvier pour la mise en service.

Je m'oriente vers une architecture par API REST en PHP pour l'application qui traitera les données. Ceci permettra, je pense, de faire évoluer l'outil dans le temps sans replonger dans tout le code et risquer de faire tout planter, et d'interfacer avec d'autres applications en se basant sur le JSON retourné. Je me pose néanmoins quelques questions sur l'architecture et j'aimerais vos retours d'expérience pour avancer. 

Supposons que je doive gérer 3 éléments : "clients", offres", et "factures". Un conteneur "projet" sera lié à un "client", et englobera "offres" et "factures" liées. "Facture" et "offre" peuvent les deux être relancées, alors que seule "facture" peut avoir un "acompte". Un "paiement" peut référer à "facture" ou "offre".

Je pense donc diviser ceci en différentes classes :

• Client
• Offres
• Factures
• Projets
• Relance
• Paiement
• Acompte

Concernant mon application, je sais déjà que je vais scinder toutes ces classes en différents fichiers. Les questions que je me pose sont liées à une organisation plus qu'à du code:

• Est-ce utile, pour ce projet, de mettre en place un autoloader pour mes classes ?
• Dois-je développer l'ensemble de mon API en un seul fichier PHP, ou alors le scinder pour correspondre aux classes envisagées et assemble le tout à base de require ?
• Est-ce-que je devrais aussi développer une classe pour le REST ou faire l'API à l'ancienne ?

J'ai des pistes de travail qui prennent en compte les futures évolutions de cette application, mais j'aimerais vos avis là dessus.

Je ferais une structure par dossier. Chaque "Objet" serait représenté par un dossier, contenant la classe et le fichier API REST en lui même, chacun dédié à l'objet en question. Un fichier index, à la racine et faisant office d'autoloder, se chargera de scruter l'ensemble des dossiers pour tout charger et faire tourner l'API complète.

Dans ce cas, pour un nouvel élément (commande par exemple), on le développe sans toucher le moindre code de l'application existante, et le tout est déployé par transfert de dossier.

Ceci n'est que ma façon de pense l'application, et j'aimerais vos retour là dessus avant d'aller plus loin.

Si vous avez d'autre pistes, d'autres idées, ou même un gros STOP à me dire, n'hésitez pas !

Merci d'avoir tout lu

Bonsoir,

je ne veux pas te décourager, mais franchement il existe des application dédiées à ce genre de problématique bien mieux faite que tu ne pourras le développer toi même en php. En plus ce genre d'application permet également de maitriser une gestion par validation de niveau hiérarchique (en gros tant qu'une étape n'est pas validée par une personne par signature numérique l'action ne va pas plus loins).

Mais toute fois si tu reste dans cette objectif je te souhaite bonne chance pour ton projet.

Merci pour la réponse, 

Je sais qu'il existe de telles solutions pour cette problématique, mais le soucis réside dans leur degrés de configuration et de possibilités.

Je n'ai absolument pas besoin de gérer des niveaux d'autorisations hiérarchiques, et mon application ne sera qu'un outil de travail. Je ne prétends pas développer le système de gestion complet à travers lequel tout passera, mais juste de quoi gérer de manière ordonnée et structurée nos document, en automatisant une partie de ce qui est fait à la main aujourd'hui ... Et techniquement il me faudrait du sur-mesure.

Crois moi, si un outil existant répondait plus ou moins à ce besoin aujourd'hui, je n'hésiterais pas longtemps avant de l'étudier et le mettre en place.

Mais sinon, merci pour tes encouragements

Pour information, j'ai bien avancé sur le développement de mon application. Je me suis concentré sur l'API pour le moment, histoire d'avoir des données afin de travailler sur la partie "client". J'ai l'ensemble des fonctions permettant de lister mes données, il me reste les ajouts/suppressions et les modifications.

Je me suis basé sur SlimPHP pour développer l'API, en adoptant une architecture me permettant, je l'espère, d'ajouter des fonctionnalités à la volée sans devoir replonger dans le code dans son intégralité.

Je passe donc en résolu