Le projet en un coup d’œil
La première version réunit sociétés, utilisateurs, clients, devis, factures, lignes, TVA, unités et génération PDF.
Docker structure PHP, Nginx et MySQL ; la CI construit ensuite les images de préproduction et de production.
TVA par ligne de devis, réglages de modèle et exception d’affichage pour une association prolongent le produit sans casser son cycle central.
eDocs commence en septembre 2017 avec une ambition très lisible : donner à une petite organisation un seul espace pour tenir ses clients, préparer ses devis, produire ses factures et envoyer des documents cohérents. Le projet porte alors le nom Artisan V1, reflet d’un outil pensé au plus près d’une gestion commerciale quotidienne.
Le sujet paraît simple tant que chaque document est regardé isolément. Il devient exigeant dès qu’il faut conserver la bonne société, le bon utilisateur, le bon client, une numérotation sans doublon, des lignes ordonnées, plusieurs taux de TVA, une mise en page propre et la continuité entre devis et facture. Une erreur à l’un de ces endroits fragilise la pièce finale.
La réponse de Dawap ne consiste donc pas à ajouter un générateur de PDF à une liste de contacts. Elle construit un modèle métier où les informations sont saisies une fois, réutilisées dans les bons parcours et protégées par des règles explicites. C’est le cœur d’un développement d’application métier réellement adapté au travail administratif.
De 2017 à 2023, ce noyau évolue sans perdre son fil : gestion multi-sociétés, brouillons de documents, transformation du devis en facture, personnalisation graphique, envoi par courrier électronique, TVA au niveau des lignes, quantités décimales, conteneurs de livraison et traitement particulier pour une structure associative.
Cette étude de cas suit ce cycle de bout en bout. Elle montre ce que l’application permet concrètement, les arbitrages inscrits dans ses parcours et les gains directement visibles dans la continuité du travail administratif.
1. eDocs, une application de gestion commerciale née comme Artisan V1
Mettre la société, ses utilisateurs et ses clients au centre du document
La première version est présentée comme une application destinée aux artisans. Son modèle répond plus largement aux besoins d’une petite structure de services : identifier l’entreprise qui émet les pièces, rattacher ses utilisateurs, enregistrer ses clients et produire les documents qui encadrent la vente.
La société constitue la racine fonctionnelle. Elle possède ses utilisateurs, ses clients, ses devis, ses factures et une configuration documentaire. Un administrateur créateur lui est rattaché, tandis qu’un slug lui donne une identité exploitable dans les parcours applicatifs.
L’utilisateur n’est pas un simple compte de connexion. Il crée les clients, devis, factures et courriers sortants qui lui appartiennent. Cette origine permet ensuite de contrôler certaines modifications et de conserver une responsabilité claire sur les documents.
Le produit distingue enfin l’administration globale des opérations courantes. Les utilisateurs authentifiés accèdent au back-office de leur activité ; les fonctions d’administration des sociétés, utilisateurs, taux de TVA et unités disposent de leurs propres espaces et niveaux d’accès.
2. Faire grandir le produit par capacités vérifiables
Un noyau documentaire enrichi pendant six années par étapes successives
La trajectoire disponible montre une construction incrémentale. Après l’identité et la connexion arrivent la génération des devis, les sociétés, les relations entre utilisateurs et entreprises, les documents, les envois et le rattachement des clients. Chaque évolution complète un parcours déjà utilisable.
Les années suivantes portent moins sur l’accumulation d’écrans que sur les contraintes réelles du document : ordre des lignes, numéros uniques, quantités décimales, informations de TVA, couleurs et typographies, calcul par taux, modèles PDF et règle particulière pour une association.
La livraison progresse elle aussi par étapes. En 2019, l’application est regroupée avec ses définitions Docker et ses volumes de documents. En 2020, une pipeline automatise la construction des images PHP et Nginx pour les environnements de préproduction et de production.
La trajectoire se lit dans ces capacités successives : construire le cycle principal, corriger ses règles documentaires, adapter ses modèles puis rendre l’environnement de livraison reproductible. Chaque étape renforce une responsabilité déjà présente plutôt que d’ouvrir un produit sans cohérence.
3. Éviter qu’un document commercial devienne une copie isolée
Client, lignes, calculs et identité visuelle doivent rester cohérents
Un devis ou une facture concentre plusieurs responsabilités. La pièce doit désigner le bon client, appliquer les bonnes coordonnées, présenter les lignes dans l’ordre attendu, calculer ses montants et porter les informations légales de l’entreprise qui l’émet.
Si ces éléments sont ressaisis séparément pour chaque document, leur cohérence dépend de vérifications humaines répétées. Le risque ne vient pas seulement d’une faute de frappe : un taux, une adresse de facturation, une référence ou un total peut diverger du dossier commercial qui devrait l’expliquer.
eDocs traite ce problème en conservant le document sous forme d’objet métier avant de le rendre en PDF. Les champs globaux, les lignes, les taxes et les relations gardent leur structure ; la mise en page ne devient que leur représentation finale.
La continuité entre devis et facture complète cette logique. Lorsqu’une proposition est convertie, les informations utiles peuvent être transférées directement au nouveau document au lieu de recommencer la saisie depuis une page blanche.
4. Définir un objectif précis pour chaque étape du cycle
Créer, contrôler, produire, envoyer puis prolonger le document
Le premier objectif est de réunir les données nécessaires à la vente dans un espace commun. La société, l’utilisateur et le client donnent au devis son contexte ; la facture s’appuie sur les mêmes repères sans créer une seconde base parallèle.
Le deuxième objectif consiste à préserver la qualité du calcul. Quantités, prix unitaires, taux de TVA et lignes ordonnées doivent produire des totaux HT, TVA et TTC cohérents, y compris lorsque plusieurs taux interviennent dans un même devis.
Le troisième objectif porte sur l’usage. L’équipe doit pouvoir commencer un brouillon, enrichir ses lignes, contrôler le rendu, générer un PDF, l’envoyer puis retrouver le document depuis une liste adaptée à sa société.
Le quatrième objectif est la capacité d’évolution. Les paramètres graphiques, les unités, les règles fiscales, les modèles et le mode de livraison doivent pouvoir changer sans transformer chaque nouvelle demande en reconstruction complète.
5. Faire de la société la frontière du produit
Documents, utilisateurs, clients et configuration partagent la même racine
Chaque société réunit ses utilisateurs, ses clients, ses devis et ses factures. Cette relation donne à l’application un périmètre organisationnel explicite : les objets commerciaux ne sont pas enregistrés sans savoir pour quelle structure ils existent.
Une configuration complète ce modèle en relation directe avec la société. Elle concentre les coordonnées, mentions, informations bancaires, logo et options de présentation nécessaires à la génération des documents.
Les listes principales utilisent la société de l’utilisateur connecté pour retrouver les clients et pièces correspondants. Les consultations de documents vérifient également cette appartenance avant d’ouvrir un devis, une facture ou son PDF.
Cet arbitrage apporte une base multi-sociétés sans mélanger leurs contextes. Le même produit peut porter plusieurs organisations, tandis que chaque document continue d’être émis avec les informations et la présentation de sa propre entreprise.
6. Relier les actions à un utilisateur authentifié
L’auteur du client ou du document reste identifiable
L’authentification s’appuie sur les utilisateurs de l’application et sur des mots de passe chiffrés. L’accès au back-office exige un rôle utilisateur, tandis que l’administration globale est réservée à un niveau supérieur.
Lorsqu’un client, un devis, une facture ou un courrier sortant est créé, son auteur est conservé. Cette relation permet d’attribuer l’opération et d’appliquer des règles plus fines que la seule présence d’une session ouverte.
La suppression et certaines modifications documentaires contrôlent ainsi le créateur. La consultation ajoute le périmètre de société, afin qu’une pièce ne soit pas ouverte depuis un compte extérieur à l’organisation qui la possède.
La sécurité reste proportionnée au produit : rôles pour les zones, société pour le périmètre et auteur pour les opérations sensibles. Le modèle ne revendique pas une matrice de permissions universelle ; il protège les parcours réellement présents.
7. Conserver un client exploitable dans les documents
Particulier ou professionnel, contact et facturation ne sont pas confondus
Le CRM permet d’ajouter, consulter, modifier et supprimer un client. Le dossier distingue notamment les informations d’un particulier de celles d’un professionnel et rassemble les coordonnées nécessaires à la relation commerciale.
L’adresse, le contact et l’adresse électronique de facturation disposent de champs dédiés. Cette séparation est utile lorsqu’un interlocuteur échange sur le projet mais que la pièce doit être envoyée à une autre boîte ou porter une autre information administrative.
Le client appartient à la société par l’intermédiaire de son créateur et se relie à ses devis et factures. Depuis le document, l’équipe ne manipule donc pas une simple chaîne de caractères : elle choisit un dossier qui conserve ses relations.
Le bénéfice est immédiatement visible dans la suite du parcours. Le PDF et le courrier utilisent un destinataire cohérent avec le dossier, tandis que les listes peuvent retrouver les pièces commerciales attachées au même client.
8. Commencer le devis sans lui donner trop tôt un statut définitif
Un document temporaire prépare la saisie avant sa première ligne
La création d’un devis produit d’abord un objet temporaire. Il reçoit son auteur, sa société, son année et une proposition de numéro construite à partir de la séquence déjà utilisée dans cette organisation.
Ce brouillon permet d’entrer dans le parcours avant que toutes les informations commerciales soient prêtes. Il évite de confondre l’ouverture d’une saisie avec l’existence d’un devis suffisamment constitué pour rejoindre les documents actifs.
L’ajout de la première ligne fait évoluer ce statut temporaire. Le produit attache ainsi la réalité du devis à son contenu plutôt qu’au seul clic qui a ouvert le formulaire.
Cet arbitrage paraît discret, mais il protège les listes et la numérotation contre des objets abandonnés au milieu d’une saisie. L’application sait distinguer une préparation technique d’une proposition qui possède déjà une matière commerciale.
9. Composer le document avec des lignes métier complètes
Libellé, description, quantité, unité, prix et taxe restent éditables
Chaque ligne de devis contient un libellé, une description, une quantité, un prix unitaire et une unité. Elle peut également recevoir son propre taux de TVA lorsque la règle fiscale ne doit pas être appliquée uniformément à toute la pièce.
Les parcours couvrent l’ajout, la modification et la suppression. Une ligne n’est donc pas figée dès sa création : elle peut être corrigée lorsque le contenu, la quantité ou le prix de la proposition évolue avant son envoi.
Les quantités acceptent des valeurs décimales. Cette évolution répond à des prestations qui ne se comptent pas uniquement en unités entières, par exemple une durée, une surface, un volume ou toute autre mesure portée par le référentiel d’unités.
La ligne reste rattachée à son devis. Son calcul, sa place et sa représentation PDF découlent de ce document précis, ce qui évite de dissocier les données commerciales de la pièce qui engage la discussion avec le client.
10. Maîtriser l’ordre des lignes et réutiliser une saisie utile
La structure du devis fait partie de sa lisibilité
Une proposition commerciale ne se lit pas toujours dans l’ordre où ses éléments ont été saisis. eDocs conserve un rang pour chaque ligne et propose des actions pour la monter ou la descendre dans le document.
Ce choix permet de regrouper les prestations, de placer un élément principal avant ses compléments ou de faire suivre une fourniture par les services qui l’accompagnent. Le rendu final respecte cet ordre explicite.
Une fonction d’autocomplétion peut retrouver des lignes déjà créées par le même utilisateur. Elle facilite la réutilisation d’un libellé ou d’une description familière sans imposer un catalogue rigide à toutes les sociétés.
Réutilisation et liberté restent ainsi équilibrées. L’utilisateur gagne un point de départ sur les prestations récurrentes, puis adapte quantité, prix, unité, description et taxe à la réalité du nouveau devis.
11. Faire évoluer la TVA du document vers la ligne
Préserver un réglage global tout en traitant les cas mixtes
Le devis possède un taux de TVA de référence. Cette approche couvre les pièces simples où toutes les lignes suivent la même règle et maintient une configuration globale rapide à comprendre.
L’évolution de décembre 2022 ajoute la TVA au niveau des lignes de devis. Le calcul peut alors distinguer plusieurs taux dans une même proposition et produire un détail fiscal correspondant aux éléments réellement vendus.
Le produit calcule la base associée à chaque taux, le montant de taxe et le détail présenté dans le document. Cette précision évite de résumer une pièce mixte à une multiplication globale qui ne représenterait pas ses lignes.
Les corrections de décembre 2022 prolongent ce travail sur le calcul et les modèles. La règle fiscale n’est pas traitée comme un texte décoratif : elle traverse le modèle, les agrégats et la présentation du PDF.
12. Revenir des totaux aux lignes qui les produisent
HT, TVA et TTC découlent du contenu du document
Le devis additionne les montants hors taxes de ses lignes à partir des quantités et des prix unitaires. Il calcule ensuite la taxe, puis le total toutes taxes comprises présenté au client.
Lorsque plusieurs taux sont utilisés, le détail conserve les bases et montants correspondants. Le total final peut ainsi être expliqué par la composition de la pièce plutôt que par une valeur enregistrée sans provenance.
La facture possède elle aussi ses lignes, son total hors taxes, son montant de TVA et son total TTC. Les deux familles documentaires partagent le même besoin de cohérence tout en conservant leurs entités et parcours propres.
Cette architecture protège les corrections. Modifier une quantité ou un prix met à jour la lecture du document depuis sa source ; l’utilisateur n’a pas à synchroniser manuellement un sous-total, une taxe et un total indépendant.
13. Produire le PDF comme une vue du dossier commercial
En-tête, contenu et pied de page sont assemblés à partir des données eDocs
eDocs utilise un moteur de rendu HTML vers PDF pour les devis et les factures. Des modèles distincts composent l’en-tête, le corps et le pied de page afin de présenter les coordonnées, lignes, totaux et mentions de manière structurée.
Les lignes sont affichées dans leur ordre métier. L’objet, la référence, les notes, les données bancaires et les informations de société complètent le tableau sans être ressaisis dans un fichier bureautique séparé.
Les documents sont rangés dans un emplacement associé à la société. Lorsqu’un utilisateur demande leur consultation, l’application contrôle le contexte avant de restituer la pièce correspondante.
Le devis dispose aussi d’une prévisualisation HTML. L’équipe peut relire la structure et les informations avant de s’appuyer sur le PDF destiné à la diffusion, ce qui rapproche la préparation et le rendu final.
14. Donner à chaque société sa propre identité documentaire
Mentions, banque, logo, couleurs et tailles restent configurables
La configuration attachée à la société réunit les informations légales et de contact nécessaires aux documents. SIRET, numéro de TVA, coordonnées et informations bancaires peuvent alimenter les modèles sans être recopiés dans chaque devis ou facture.
Le logo apporte l’identité visuelle principale. Des couleurs dédiées au document, au tableau et à ses éléments permettent d’adapter le rendu au langage graphique de l’organisation.
Les tailles de police font elles aussi partie des réglages. L’objectif n’est pas de transformer eDocs en outil de mise en page libre, mais de donner assez de latitude pour produire des pièces cohérentes avec la société qui les signe.
Cet équilibre protège les deux dimensions du document : une structure commune maintient les règles de calcul et de lecture, tandis que les paramètres de société évitent un rendu générique identique pour toutes les organisations.
15. Envoyer le devis ou la facture depuis son propre parcours
Destinataire, objet, contenu et pièce jointe restent reliés
Les devis et factures possèdent chacun une action d’envoi par courrier électronique. Le formulaire recueille le destinataire, le sujet et le contenu, puis vérifie la validité de l’adresse avant de déclencher l’expédition.
Le PDF correspondant est joint au message. L’adresse de réponse renvoie vers l’utilisateur connecté, ce qui permet au client de poursuivre l’échange avec la personne qui porte réellement le document.
Le courrier sortant est enregistré avec son destinataire, son sujet, son contenu, son expéditeur et sa date d’envoi. La création du message ne disparaît donc pas entièrement une fois la pièce transmise.
Cette continuité évite un détour par plusieurs outils pour fabriquer puis joindre le document. Le dossier, son rendu et sa diffusion sont traités dans le même environnement fonctionnel.
16. Créer une facture sans imposer le passage par un devis
Le produit conserve un parcours autonome quand la vente le demande
Une facture peut être créée indépendamment. Comme le devis, elle commence sous une forme temporaire, reçoit sa société, son auteur, son année et une proposition de numéro issue de la séquence de l’organisation.
Ses informations globales comprennent le client, l’objet, la référence, les textes d’en-tête et de pied de page ainsi que la TVA. Ses lignes conservent libellé, description, quantité, unité, prix et ordre.
Des actions dédiées permettent d’ajouter, modifier, déplacer ou supprimer les lignes. La facture reste ainsi éditable dans son propre cycle lorsque le document ne découle pas d’une proposition enregistrée dans eDocs.
Ce parcours autonome constitue un choix important. La transformation devis-facture accélère les cas liés, mais elle ne devient pas une contrainte artificielle pour les factures qui ont une autre origine.
17. Transformer le devis en facture sans ressaisir la vente
Le client, les textes, la taxe et chaque ligne traversent le changement de document
L’action de transformation crée une facture directement depuis un devis. Elle reprend le client, l’année, les descriptions d’en-tête et de pied de page, l’objet, la référence, la TVA, l’auteur et la société.
Chaque ligne est copiée avec sa description, son libellé, son ordre, sa quantité, son prix unitaire et son unité. La facture retrouve donc la structure commerciale qui a déjà été préparée dans la proposition.
La nouvelle pièce est reliée au devis source et quitte le statut temporaire. Le lien entre les deux documents reste disponible pour expliquer d’où vient la facture et empêcher certaines opérations incohérentes sur la proposition initiale.
Le gain est directement observable dans le parcours : les informations déjà présentes ne doivent pas être retapées, les lignes conservent leur ordre et le contexte commercial reste attaché.
18. Bloquer les opérations qui casseraient l’histoire documentaire
Numéros uniques, auteur et facture liée encadrent les modifications sensibles
La vérification de doublon sur les numéros protège l’identité des devis. Deux pièces ne doivent pas devenir indiscernables au moment de les classer, de les envoyer ou de les retrouver depuis une conversation.
La suppression d’un devis exige que l’utilisateur en soit le créateur. Elle est aussi refusée lorsque le devis a déjà produit une ou plusieurs factures, car retirer la source ferait disparaître une partie de la continuité commerciale.
Lorsque cette relation bloque la suppression, l’application peut indiquer les numéros de facture concernés. L’utilisateur comprend alors la cause du refus au lieu de recevoir une interdiction sans contexte.
Les consultations de devis, factures et PDF ajoutent le contrôle de société. Ces garde-fous ne remplacent pas toutes les politiques possibles, mais ils couvrent les incohérences les plus directement liées au cycle présent dans eDocs.
19. Retrouver clients et documents dans le périmètre courant
Les listes opérationnelles partent de la société de l’utilisateur
Le tableau de bord et les contrôleurs de listes donnent accès aux clients, devis et factures utiles à l’organisation connectée. Les recherches appliquent le périmètre de société porté par l’utilisateur.
Les documents temporaires peuvent rester distingués des pièces constituées. Cette séparation évite de faire remonter une saisie abandonnée au même niveau qu’un devis ou une facture contenant déjà ses lignes.
Depuis les listes, l’équipe rejoint les actions adaptées au type de document : consultation, édition des informations, gestion des lignes, production PDF, envoi ou transformation lorsqu’il s’agit d’un devis.
Le back-office agit comme une porte d’entrée vers le cycle. Sa valeur se trouve dans la capacité à retrouver le bon objet puis à poursuivre son action avec le contexte déjà enregistré.
20. Administrer le référentiel sans polluer la saisie quotidienne
Sociétés, utilisateurs, TVA et unités possèdent leurs propres écrans
Les sociétés et utilisateurs disposent de fonctions d’administration dédiées. Ce périmètre permet de créer la structure organisationnelle et les comptes qui utiliseront ensuite les clients et documents.
Les taux de TVA appartiennent eux aussi au référentiel administrable. L’application ne force pas les formulaires métier à redéfinir un taux libre à chaque ligne ; elle s’appuie sur des objets contrôlés et réutilisables.
Les unités suivent la même logique. Elles donnent du sens aux quantités utilisées dans les devis et factures et peuvent évoluer dans un espace distinct du document commercial.
Séparer ces réglages des opérations courantes réduit la charge de chaque écran. L’utilisateur qui prépare une pièce choisit une valeur existante ; l’administrateur conserve la responsabilité de faire évoluer le vocabulaire commun.
21. Traiter le cas d’une association dans le modèle documentaire
Une évolution 2023 adapte la facture à un contexte sans TVA
La dernière évolution disponible, datée du 22 février 2023, ajoute une information permettant d’identifier une société associative. Le même indicateur apparaît également côté client pour compléter le contexte concerné.
Dans le modèle de facture, le comportement associé masque les lignes récapitulatives de TVA et de TTC pour cette société. Le document ne se contente donc pas d’un changement de logo : sa présentation fiscale s’adapte au statut enregistré.
Cette évolution accompagne aussi un logo et des ajustements de modèle pour le contexte Combine. Elle montre comment le produit peut absorber une exception réelle sans dupliquer toute la gestion des clients, lignes et factures.
L’arbitrage consiste à conserver un cycle commun tout en faisant varier la présentation là où le statut de l’organisation le justifie. La différence reste localisée au document au lieu de créer une seconde application indépendante.
22. Décrire l’environnement d’exécution avec le produit
PHP, Nginx, MySQL et stockage documentaire deviennent reproductibles
En mai 2019, l’application est réorganisée avec ses fichiers Docker. La composition réunit le runtime PHP, le serveur Nginx et une base MySQL, avec un service d’administration de base pour l’environnement prévu.
Les journaux, fichiers applicatifs et données persistantes sont identifiés par des volumes. Les documents et téléversements ne sont pas traités comme des fichiers jetables enfermés dans une image qui disparaîtrait à chaque redémarrage.
Cette description rapproche l’application de son mode réel d’exécution. Une nouvelle installation peut retrouver les mêmes rôles techniques au lieu de dépendre uniquement d’une configuration manuelle connue d’un poste historique.
La conteneurisation ne modernise pas automatiquement le socle Symfony 2.8, mais elle stabilise la manière de le lancer et de séparer les responsabilités entre application, serveur web et base de données.
23. Construire quatre images selon l’environnement et le rôle
PHP et Nginx sont produits pour préproduction comme pour production
La chaîne d’intégration ajoutée en 2020 définit quatre constructions : une image PHP et une image Nginx pour la préproduction, puis leurs équivalents destinés à la production.
Chaque rôle conserve son image et sa configuration. Le serveur web n’est pas fondu dans le runtime PHP, ce qui facilite la lecture de l’architecture et la reproduction des environnements attendus.
Les images sont construites puis publiées dans le registre prévu par la chaîne. Le livrable ne se limite donc plus à des fichiers sources : l’environnement produit des artefacts prêts à être utilisés dans le déploiement correspondant.
Cette étape complète la maturité du projet : l’application, le serveur web et leurs deux environnements suivent une construction automatisée, lisible et séparée par responsabilité.
24. Lire la qualité dans les tests et les corrections successives
Le produit possède des contrôles, mais la preuve reste proportionnée
Le projet conserve plusieurs tests applicatifs et une configuration de test Symfony. Ils montrent que certains comportements ont été préparés pour être exercés hors de l’usage manuel de l’interface.
L’historique porte aussi des corrections ciblées sur les documents : numérotation, présentation, quantités, TVA, modèles et calculs. Ces changements concernent précisément les zones où une petite incohérence peut produire une pièce erronée.
La qualité vient également des contraintes du modèle : relations obligatoires, auteurs, sociétés, numéros contrôlés, document temporaire, lignes ordonnées et blocage de suppression lorsqu’une facture dépend du devis.
Ensemble, ces éléments donnent une chaîne de qualité concrète : des tests applicatifs, des règles qui protègent le modèle, des corrections ciblées sur les documents et une construction automatisée par environnement.
25. Résumer les arbitrages qui donnent sa cohérence à eDocs
Un modèle commun, des parcours distincts et des exceptions localisées
Premier arbitrage : placer la société au-dessus des utilisateurs, clients et documents. Cette frontière permet de partager le produit tout en conservant coordonnées, configuration et pièces dans leur contexte organisationnel.
Deuxième arbitrage : distinguer devis et facture. Ils partagent des principes de lignes et de calcul, mais gardent leurs entités, actions et numérotations afin que chacun conserve son cycle propre.
Troisième arbitrage : copier les informations lors de la transformation tout en maintenant le lien avec le devis source. La facture devient autonome sans perdre la provenance commerciale qui l’a générée.
Quatrième arbitrage : centraliser la structure du PDF et laisser la configuration de société personnaliser son identité. Cinquième arbitrage : traiter la TVA mixte et le cas associatif là où leur différence a un effet réel.
26. Rendre les gains visibles dans le parcours quotidien
Moins de ressaisie, plus de continuité et un document plus explicable
Le premier gain est la continuité de la donnée. Société, auteur et client suivent le devis ; ses lignes produisent les calculs ; le PDF reprend le dossier ; l’envoi joint cette pièce ; la facture peut enfin être créée depuis la proposition.
Le deuxième gain est la réduction des ressaisies imposées par le parcours. Transformer un devis copie les informations et ses lignes, tandis que la configuration de société alimente les coordonnées, mentions, banque et identité visuelle des documents successifs.
Le troisième gain est l’explicabilité. Un total revient à ses lignes, un détail de TVA revient à ses taux, une facture revient à son devis et un document revient à la société ainsi qu’à l’utilisateur qui l’a créé.
Le quatrième gain est la capacité d’adaptation. Quantités décimales, TVA par ligne, réglages graphiques et cas associatif ont été ajoutés sans abandonner le cycle central construit en 2017.
27. Suivre un devis depuis le client jusqu’à la facture envoyée
Un scénario concret traverse les principales responsabilités du produit
Un utilisateur authentifié commence par créer ou retrouver le client de sa société. Le dossier conserve les informations de contact et l’adresse électronique de facturation qui pourront être utilisées dans la relation documentaire.
Il ouvre ensuite un devis temporaire. Il choisit le client, précise l’objet et la référence, ajoute les textes utiles puis compose des lignes avec libellés, descriptions, quantités, unités, prix et taux de TVA adaptés.
Les lignes sont réordonnées pour rendre la proposition lisible. eDocs calcule le hors taxes, détaille les taxes puis produit le TTC. La prévisualisation et le PDF reprennent la configuration visuelle, les coordonnées et les données bancaires de la société.
Le devis peut être envoyé avec son PDF. Lorsque la vente doit être facturée, l’action de transformation crée la nouvelle pièce, recopie le contexte et chaque ligne, puis conserve le lien vers la proposition. La facture peut à son tour être générée et transmise depuis son parcours.
28. Préparer la suite à partir des responsabilités déjà bien séparées
Moderniser le socle sans perdre les règles qui rendent le document fiable
La dernière étape disponible conserve un socle Symfony 2.8 devenu ancien. Une évolution future devrait donc traiter la modernisation technique tout en protégeant les relations et calculs qui donnent sa valeur au produit.
Les invariants sont identifiables : frontière de société, auteur, séquences documentaires, statuts temporaires, ordre des lignes, calculs de TVA, transformation du devis en facture, configuration et accès aux fichiers produits.
Une migration d’application Symfony legacy pourrait progresser par domaines : identité et sociétés, clients, devis, factures, documents, puis administration et livraison.
Cette lecture évite de confondre modernisation et réécriture d’écrans. La priorité est de conserver les règles qui empêchent la ressaisie et les incohérences, puis de leur donner un socle maintenable pour les prochaines évolutions.
29. Conclusion
Pourquoi ce projet donne envie de travailler avec Dawap
eDocs raconte une transformation simple à formuler mais exigeante à exécuter : faire d’un devis autre chose qu’un fichier final. Le produit relie la pièce à une société, un auteur, un client, des lignes ordonnées, des calculs, une configuration et une éventuelle facture.
Sa trajectoire de 2017 à 2023 montre aussi la vie réelle d’un outil métier. Après le noyau arrivent la livraison conteneurisée, les quantités décimales, la TVA par ligne, les réglages de modèle et une exception associative. Le produit grandit en absorbant des contraintes précises, pas en empilant des promesses génériques.
La preuve la plus forte reste le parcours complet : saisir une fois, produire le document, l’envoyer, puis prolonger le devis en facture sans perdre son contexte. C’est exactement ce qu’un back-office métier sur mesure doit apporter lorsque les documents commerciaux structurent le quotidien.
