Le projet en un coup d’œil
Clients, contacts, projets, activités, offres, devis, factures, règlements, frais, timelines et serveurs composent un même back-office.
Le produit adopte Docker et quatre constructions d’images pour séparer PHP et Nginx en préproduction comme en production.
Phoenix concentre sa première trajectoire sur clients, devis, factures, encaissements, charges, API et import des données historiques.
Dawap ERP commence le 4 avril 2017 avec une matière très concrète : représenter l’activité d’une agence qui vend des prestations, réalise des projets, émet des documents commerciaux, suit ses clients et doit relire sa situation comptable. La réponse prend la forme d’un back-office Symfony dédié aux opérations internes.
Cette première génération grandit vite. Elle distingue les projets web package, les prestations web et les formations ; elle compose des devis à partir de packages, modules, options ou lignes libres ; elle suit activités, tâches, appels et rendez-vous ; elle génère factures, timelines et documents PDF ; elle organise enfin charges, frais kilométriques, règlements et serveurs.
En 2019, l’enjeu se déplace aussi vers la livraison. PHP et Nginx disposent d’images propres pour la préproduction et la production. Le produit ne repose plus uniquement sur son code métier : son mode d’exécution devient lui aussi décrit et reproductible.
Le 27 novembre 2020, Phoenix ouvre une seconde génération. Elle ne cherche pas à reproduire immédiatement les cinquante-trois entités de l’ancien ERP. Elle repart d’un noyau centré sur les comptes, clients, devis, factures, lignes, encaissements et charges, puis construit les imports et interfaces nécessaires pour relire ces données dans un socle Symfony 4.4.
Cette étude de cas raconte cette continuité comme un seul chantier de refonte de logiciel métier : modéliser largement l’activité, apprendre de cette première couverture, puis choisir les données à préserver lorsqu’une nouvelle fondation devient nécessaire.
1. Dawap comme premier utilisateur de son propre outil métier
Faire cohabiter production, vente et comptabilité dans un système adapté à l’agence
Une agence numérique travaille simultanément sur des relations commerciales, des projets en cours, des documents contractuels, des actions de production et une lecture financière. Ces dimensions avancent à des rythmes différents mais se rattachent aux mêmes clients et aux mêmes engagements.
Le produit doit également composer avec plusieurs natures d’offre. Un web package possède un catalogue de modules et d’options ; une prestation se construit avec des lignes plus libres ; une formation suit un projet spécifique. Un modèle unique trop simplifié ferait perdre le sens de ces différences.
Le suivi quotidien possède sa propre granularité. Une note, un appel, une tâche programmée, un rendez-vous et une activité de projet ne sont pas interchangeables. Leur rattachement au bon client ou au bon projet détermine la qualité de la prochaine action.
Enfin, le pilotage financier ne se limite pas au chiffre d’affaires facturé. Charges, frais, encaissements, impayés, TVA, remises et lignes de facture doivent pouvoir être lus par période et par client. Dawap ERP rapproche ces objets sans les fondre dans un statut universel.
2. Faire évoluer le modèle en suivant les responsabilités réelles
De la couverture opérationnelle large à un noyau financier migrable
La première génération adopte un découpage par domaines. Production rassemble clients, collaborateurs, projets et activités. Documents porte devis, factures et timelines. Comptabilité traite charges, notes de frais, frais kilométriques et règlements. Business Plan structure les packages, modules et options utilisés dans les offres web.
Les écrans restent reliés par les objets communs. Un client ouvre sur ses contacts, activités et projets ; un projet web choisit un package et des options avant d’accéder au devis ; une timeline reçoit ses itérations et ses actions ; une facture rejoint ensuite les vues de documents et de comptabilité.
Phoenix change d’échelle et de frontière. Le compte devient la racine qui isole utilisateurs, clients, factures, écritures et charges. Les contrôleurs API et back-office utilisent les mêmes ressources, tandis que les références de migration conservent le lien avec les identifiants historiques.
Cette seconde génération se construit du 27 novembre au 3 décembre 2020. Son objectif observable est précis : importer et relire le cœur financier dans un modèle modernisé, puis calculer une vision mensuelle et annuelle à partir des factures, encaissements, charges et clients.
3. Commencer par les objets qui font réellement vivre l’agence
Le 4 avril 2017, le premier Dawap ERP entre dans son histoire applicative
Le point de départ n’est pas un catalogue de fonctionnalités génériques. Le produit représente d’abord les clients, contacts, collaborateurs, projets, activités, devis et factures que Dawap manipule pour vendre puis réaliser ses prestations.
Dès les premières semaines, le périmètre s’étend aux frais kilométriques, à la webothèque et aux documents. Le front initial est ensuite retiré afin de concentrer l’application sur son rôle d’ERP interne et sur les écrans nécessaires aux opérations.
Ce choix donne au projet une direction claire : le back-office devient le produit. Il n’est pas une interface d’administration secondaire ajoutée derrière un site ; il porte la relation client, la production, les documents et la lecture comptable.
L’historique compte quatre-vingt-huit changements jusqu’au 28 novembre 2019. Il permet de suivre les évolutions fonctionnelles, les corrections sur les devis et factures, l’arrivée des timelines, puis la mise en conteneurs du produit.
4. Séparer production, documents, comptabilité et catalogue commercial
Cinquante-trois entités répartissent les responsabilités du premier ERP
Le domaine Production concentre les éléments les plus proches de l’exécution : client, contact, collaborateur, projet, activité, instance, univers et serveur. Des variantes de projet distinguent web package, prestation web, prestation et formation.
Le domaine Documents prend en charge plusieurs familles de devis, leurs lignes, les factures et les timelines. Chaque document conserve le vocabulaire de l’offre à laquelle il appartient plutôt que d’utiliser une seule structure réduite au prix final.
La comptabilité possède ses objets dédiés : charge, note, frais kilométrique et lignes de facture. Les règlements sont consultés selon la nature de l’activité, notamment formation, prestation, web package et prestation web.
Business Plan porte enfin packages, modules, options, catégories et types d’option. Ce catalogue commercial peut être utilisé dans la composition d’un projet web sans être confondu avec le projet effectivement vendu.
5. Relier le client à ses contacts, projets et activités
La fiche tiers devient une porte d’entrée sur la relation complète
Le back-office distingue contacts commerciaux et clients. Une action de transformation fait évoluer le statut du tiers lorsque la relation change, tandis que la fiche continue de porter les informations déjà rattachées.
Les contacts appartiennent au client et possèdent leurs propres écrans de création, consultation et modification. Cette séparation évite de réduire une organisation à une seule adresse ou à un interlocuteur figé.
Les collaborateurs sont également représentés. Ils peuvent être créés et modifiés, puis intervenir dans le suivi de l’activité sans occuper la même place que les utilisateurs d’administration ou que les contacts clients.
Depuis un client, l’ERP peut retrouver les projets et les actions qui racontent la relation. Cette continuité prépare les devis et les factures : la pièce commerciale ne flotte pas sans tiers ni historique.
6. Donner un type précis à chaque interaction opérationnelle
Notes, messages, appels, tâches et rendez-vous dans le fil du client
Une activité peut être ajoutée sur un projet ou sur un client. Les parcours différencient la note, le message interne, l’appel, la tâche programmée et le rendez-vous programmé afin de conserver l’intention de chaque action.
Les listes peuvent isoler les notes et les tâches. L’utilisateur retrouve ainsi une file adaptée à ce qu’il doit relire ou exécuter, sans demander à un texte libre de jouer le rôle de statut.
Une activité existante peut être modifiée, marquée comme favorite ou supprimée. Ces opérations donnent au fil une vie propre : l’historique sert à travailler, pas uniquement à archiver ce qui s’est passé.
Le rattachement au projet complète la lecture client. Une action générale reste sur le compte ; une opération qui appartient à une livraison précise rejoint le contexte où ses échéances et ses objectifs prennent sens.
7. Adapter le projet à la nature de ce qui est vendu
Web package, prestation web, prestation et formation suivent des parcours distincts
Le projet générique conserve le client, le type et les informations partagées. Des entités spécialisées ajoutent ensuite ce qui appartient à chaque famille : ProjetWeb, ProjetWebPrestation, ProjetPrestation et ProjetFormation.
Les écrans de création peuvent partir d’un client et d’un type de projet. La consultation redirige ensuite vers la représentation adaptée, ce qui évite d’afficher les mêmes champs à une formation et à un web package.
Pour les prestations, des instances détaillent les unités de travail liées au projet. Pour le web package, le parcours s’appuie plutôt sur un package, ses modules, ses options, le devis correspondant et la validation d’un acompte.
Les actions de démarrage, d’archivage des devis et de suppression encadrent le cycle du projet web. Le produit représente ainsi plusieurs moments de la vente et de l’exécution sans imposer un workflow identique à toutes les offres.
8. Composer une offre web avec packages, modules et options
Le catalogue commercial alimente le projet sans remplacer ses données propres
Un package regroupe des modules et peut recevoir des options classées par type. Les catégories permettent d’organiser ce catalogue et de le faire évoluer indépendamment des dossiers clients déjà créés.
Lorsqu’un projet web choisit un package, les lignes correspondantes sont matérialisées dans le devis. L’équipe peut ensuite modifier ou réinitialiser une ligne de module ou d’option lorsque les conditions du dossier l’exigent.
Des lignes standards complètent les éléments du catalogue. Elles donnent la liberté d’ajouter une prestation spécifique sans déformer le package de référence pour tous les futurs projets.
Cet arbitrage combine réutilisation et personnalisation. Le catalogue accélère la composition des offres récurrentes ; les lignes du document conservent la réalité commerciale du client concerné.
9. Distinguer le devis web package du devis de prestation
Deux parcours documentaires pour deux logiques de vente
Le devis web package s’appuie sur les lignes de package, modules, options et lignes standards. Les écrans permettent d’ajuster ces composants puis de produire une prévisualisation client ou une vue d’administration.
Le devis de prestation possède son propre contrôleur, ses propres lignes et ses propres modèles. Il n’est pas forcé dans la structure du catalogue web lorsque la mission demande une composition différente.
Le produit gère aussi le choix d’un PDF signé et l’archivage des devis associés au projet. Ces actions montrent que le document suit un cycle après sa composition : préparation, validation, signature et conservation.
Les corrections historiques sur l’ordre des lignes et sur le prix des offres illustrent un point essentiel : dans un ERP, la présentation d’un devis et la règle de calcul appartiennent à la même promesse commerciale.
10. Prolonger le projet jusqu’à la facture et au règlement
Facturation de package, prestation, hébergement et pièces standards
La première génération possède des parcours de facturation dédiés aux prestations et aux web packages. Les tableaux de bord retrouvent les projets à facturer et les devis qui donnent leur contexte aux montants.
Une facture standard peut être créée en dehors de ces deux parcours, notamment pour l’hébergement. Ses lignes restent éditables afin de représenter une pièce qui ne découle pas directement du catalogue de packages.
Les vues de règlements sont séparées par activité : formation, prestation, web package et prestation web. Cette distinction aide à relire les encaissements selon la source commerciale qui les a produits.
L’application peut envoyer une facture ou une facture pro forma par courrier électronique. La génération du document, le tiers et sa diffusion restent ainsi reliés dans le même back-office.
11. Faire entrer les charges, notes et frais dans la lecture de l’activité
Le chiffre facturé ne suffit pas à piloter une agence
Le domaine comptable dispose d’un tableau de bord et de vues clients. Il rapproche la facturation de données qui représentent les dépenses et les mouvements nécessaires à une lecture plus complète.
Les charges possèdent leurs écrans de création et de modification. Les notes de frais peuvent être créées seules, sur un client ou sur un projet, puis passer par des actions de validation et de comptabilisation.
Les frais kilométriques suivent également leur cycle de création, modification et suppression. Leur existence comme objet métier évite qu’un déplacement reste un montant sans contexte ni date.
Chaque famille conserve donc sa responsabilité. Une charge, une note et un règlement peuvent tous modifier la lecture financière, mais ils ne décrivent ni la même origine ni la même action à mener.
12. Transformer la trajectoire d’un projet en document structuré
Timelines, itérations et actions décrivent la livraison attendue
Une timeline peut être créée, consultée et modifiée. Elle reçoit des itérations, auxquelles les actions donnent un niveau de détail supplémentaire pour raconter la progression prévue du projet.
Chaque action peut être ajustée ou supprimée. Une itération peut également être retirée lorsque la structure de la trajectoire change, sans imposer la conservation d’un découpage devenu incorrect.
La timeline possède sa propre génération PDF. Elle devient alors un livrable partageable, produit depuis les mêmes éléments que ceux utilisés par l’écran de pilotage.
Cette fonction relie planification et communication. Le produit ne se contente pas de lister des tâches internes ; il peut restituer une séquence compréhensible à partir du modèle de projet.
13. Conserver le contexte d’hébergement à côté des projets
Les serveurs rejoignent le référentiel d’exploitation
Le premier ERP possède un tableau de bord consacré à l’hébergement et un référentiel de serveurs. Un serveur peut être créé puis modifié dans le back-office.
Cette fonction replace l’infrastructure dans le contexte de l’agence. La livraison d’un projet web ne s’arrête pas toujours au code ou à la facture ; elle peut se prolonger par un environnement qu’il faut identifier et maintenir.
Le référentiel ne remplace pas un outil de supervision. Il donne une adresse métier aux informations d’hébergement nécessaires pour retrouver ce qui appartient au portefeuille géré.
Ce périmètre enrichit la lecture du projet web : offre, production, documents, facturation et hébergement peuvent être suivis par la même application sans être confondus.
14. Produire les pièces depuis les objets du back-office
Devis, factures et timelines partagent un moteur PDF
Les modèles Twig couvrent les vues d’administration, les prévisualisations et les versions destinées au client. Le produit sépare ce qui sert à travailler de ce qui doit être remis ou imprimé.
wkhtmltopdf, intégré avec KnpSnappy, transforme ces restitutions en fichiers PDF. Les documents utilisent les lignes, prix, descriptions et relations déjà présents dans l’ERP.
La webothèque complète ce dispositif avec images, fichiers, documents et leurs types. Elle offre un rangement administrable pour les ressources qui accompagnent les pages et les livrables.
Le document découle ainsi d’un dossier structuré. Une facture, un devis ou une timeline conserve son origine dans le produit qui l’a généré.
15. Faire du back-office un poste de travail configurable
Utilisateurs, pages, sections, médias et informations d’entreprise
Le domaine Back prend en charge utilisateurs, configuration, contacts, sujets de contact, pages et sections. Des variantes système distinguent les composants structurants des contenus éditables plus ordinaires.
La configuration rassemble notamment informations client, informations bancaires, réseaux sociaux, langues et ressources d’interface. Ces éléments peuvent alimenter les documents sans être répétés dans chaque modèle.
La webothèque possède des entrées dédiées aux images, fichiers et documents ainsi qu’à leurs types. L’administration peut donc classer les ressources au lieu de les déposer sans métadonnée dans un répertoire commun.
Au total, deux cent soixante-sept vues Twig de premier niveau composent les écrans et documents de cette génération. Cette étendue reflète les nombreux rôles du produit, du suivi commercial à la production PDF.
16. Passer en 2019 d’une application locale à des images par environnement
PHP et Nginx deviennent des artefacts de livraison distincts
Le 21 juin 2019, la composition Docker rejoint l’application. PHP-FPM, Nginx et MySQL forment l’environnement local décrit par le projet, avec des configurations adaptées à leurs responsabilités.
La pipeline construit quatre images : PHP et Nginx pour la préproduction, puis PHP et Nginx pour la production. Chaque job publie son image dans le registre du projet avec une étiquette liée au changement.
Cette séparation rend les cibles explicites. Le serveur web et l’exécution PHP n’ont pas besoin d’être confondus dans une seule image ; préproduction et production peuvent recevoir leurs propres paramètres de construction.
L’industrialisation protège la capacité à reconstruire et déplacer l’environnement sans dépendre uniquement d’une installation manuelle connue d’une personne.
17. Reconnaître qu’une couverture large ne dicte pas la forme de la refonte
La seconde génération choisit un noyau au lieu d’une copie écran par écran
À la fin de 2019, le premier ERP couvre de nombreux domaines avec cinquante-trois entités, soixante-quatre contrôleurs applicatifs et plusieurs centaines de vues. Cette richesse constitue un patrimoine métier, mais elle ne désigne pas automatiquement le premier lot d’une nouvelle architecture.
Phoenix démarre fin 2020 avec douze classes dans son domaine principal. Compte, utilisateur, client, devis, facture, lignes, encaissement, charge et types associés forment le périmètre de reprise visible.
Le choix est cohérent avec une migration progressive d’application Symfony : définir les objets qui doivent survivre, conserver leur provenance puis reconstruire les écrans qui exploitent ce noyau.
Les fonctions de production, timeline, catalogue de packages ou hébergement restent des capacités de la première génération et des candidats distincts pour d’autres lots.
18. Faire du compte la frontière du nouveau modèle
Utilisateurs, clients et écritures restent isolés par organisation
Dans Phoenix, le compte possède ses utilisateurs, clients, types de charges, charges, types d’encaissements, encaissements et factures. Cette racine donne un propriétaire explicite aux données financières.
Le client porte coordonnées, SIRET, adresse de facturation et référence de migration. Il se relie aux devis, factures et encaissements sans devenir lui-même le conteneur technique de toutes les données.
La facture distingue montants avant remise, remise fixe ou en pourcentage, montants hors taxes, TVA, TTC, montant à payer et état de règlement complet. Ses lignes conservent quantité, prix unitaire, description, position et totaux.
Les charges et encaissements portent leur date, leurs montants HT, TVA et TTC, leur compte bancaire éventuel, leur type et leur référence de migration. Chaque objet financier reste précis.
19. Construire sept commandes pour reprendre l’histoire financière
Clients, devis, factures, lignes et exports comptables suivent des chemins explicites
Phoenix contient des commandes dédiées à l’import des clients, des devis, des factures et des lignes de facture. Chaque famille peut être reprise séparément, ce qui évite de cacher toute la migration dans un unique script difficile à relire.
Deux variantes prennent en charge des sources Enki pour les factures et Tiime pour les données comptables. Les imports créent types de charge et d’encaissement lorsque cela est nécessaire, puis rattachent chaque écriture au compte concerné.
Les références de migration sont conservées sur les clients, devis, factures, lignes, charges et encaissements. Elles permettent de retrouver l’identité historique utilisée lors d’une reprise ou d’éviter la création répétée du même objet.
La donnée n’arrive pas comme un chargement opaque : elle passe par des règles qui reconstruisent les relations attendues par le nouveau modèle.
20. Aligner les ressources API et les écrans du back-office
Compte, client, devis, facture, encaissement et charge possèdent leurs points de lecture
Phoenix expose des contrôleurs API pour les comptes, clients, devis, factures, encaissements, charges et utilisateurs. Les recherches sont paginées et la couche Doctrine filtre les résultats dans le périmètre du compte.
Le back-office propose en parallèle les listes de recherche et les fiches de compte, client, facture ou devis. Il interroge les ressources HTTP du produit avec le jeton de l’utilisateur connecté.
Cette séparation rend l’API utile à l’interface elle-même. Le contrat de données n’est pas réservé à une intégration future : il alimente déjà la lecture des ressources dans Phoenix.
Le projet illustre une application ERP connectée : les écrans internes et les endpoints partagent le même domaine, les mêmes comptes et les mêmes règles de recherche.
21. Faire suivre l’identité du web jusqu’à l’API
Rôles hiérarchiques, jeton d’accès et filtrage par compte
La sécurité web distingue utilisateur, commercial, administrateur et super-administrateur dans une hiérarchie de rôles. Les routes du back-office exigent un utilisateur authentifié, tandis que les fonctions d’administration disposent d’un niveau supérieur.
L’API utilise un mécanisme d’authentification par jeton et reste sans session serveur. La connexion du back-office obtient l’identité du service puis conserve le jeton nécessaire aux appels suivants.
Les recherches de clients, devis, factures, charges et encaissements reçoivent le compte de l’utilisateur. Ce filtre maintient la frontière fonctionnelle entre organisations.
L’inscription crée un compte dédié puis rattache le nouvel utilisateur. Le produit établit ainsi son périmètre avant que les premières ressources financières soient ajoutées ou importées.
22. Reconstruire la lecture financière mois par mois
Factures payées, impayés, charges et encaissements dans une même grille
Le tableau de bord Phoenix interroge factures, charges, encaissements, clients et compte. Il répartit ensuite les montants par année et par mois afin de produire une lecture comparable du fonctionnement de l’agence.
Les factures réglées et non réglées restent distinguées. Pour chacune, le calcul conserve HT, TVA et TTC ainsi que le détail des pièces qui composent l’agrégat du mois.
Les charges et encaissements suivent la même logique de période. Une estimation du compte bancaire additionne les entrées et retranche les sorties ; les vues détaillées permettent de revenir des totaux aux objets qui les expliquent.
La répartition par client complète la lecture globale. Le tableau annuel et les graphiques mensuels montrent la contribution de chaque client sans détacher le chiffre de ses factures sources.
23. Livrer Phoenix avec son application web et son infrastructure de workers
Symfony 4.4, Docker, Nginx, PHP et RabbitMQ dans le même projet
Phoenix repose sur PHP 7.1.3 minimum et Symfony 4.4. Doctrine 2.7 gère les entités, le composant HTTP Client sert les appels applicatifs et Messenger prépare les traitements asynchrones.
La composition locale réunit PHP, Nginx et RabbitMQ, avec une image dédiée à la consommation de messages. Un gestionnaire peut lire la profondeur de la file pour rendre cette infrastructure accessible au produit.
La pipeline construit deux images principales : PHP et Nginx. Les jobs s’exécutent sur les branches prévues pour le développement et la livraison, puis publient les artefacts dans le registre.
Cette génération rassemble le modèle, les imports, l’API, le back-office et leur environnement. Elle atteint son dernier jalon disponible le 3 décembre 2020, six jours après la création du projet.
24. Lire la trajectoire à travers cinq arbitrages concrets
Ce que Dawap ERP conserve, spécialise puis reconstruit
Premier arbitrage : spécialiser les projets et documents lorsque leurs règles diffèrent. Web package, prestation et formation partagent un client mais ne sont pas réduits aux mêmes lignes ni aux mêmes actions.
Deuxième arbitrage : produire les documents depuis le modèle. Devis, factures et timelines utilisent les objets de l’ERP, ce qui maintient le lien entre une pièce et le dossier qui l’explique.
Troisième arbitrage : séparer le catalogue de l’offre vendue. Packages, modules et options restent réutilisables, tandis que les lignes du devis peuvent être adaptées au projet précis.
Quatrième arbitrage : isoler l’exécution par environnement en 2019. Cinquième arbitrage : reconstruire dans Phoenix un noyau financier avec des références de migration et une frontière de compte.
25. Nommer les gains que les deux générations rendent visibles
Une transformation démontrable dans les parcours et les données
La première génération donne une continuité opérationnelle. Depuis le client, Dawap peut retrouver contacts, activités et projets ; depuis le projet, rejoindre l’offre, le devis, la timeline, la facturation et les éléments d’exploitation associés.
La spécialisation préserve le sens. Une option de package, une ligne de prestation, une note de frais et un règlement ne deviennent pas quatre variations d’un même objet générique impossible à interpréter.
L’industrialisation protège la livraison. Les images de préproduction et de production rendent les rôles PHP et Nginx explicites et reproductibles hors du poste où l’application a été développée.
Phoenix apporte enfin une voie de reprise. Les données historiques gardent une référence, les ressources sont isolées par compte, l’API alimente le back-office et le tableau financier peut revenir de chaque total mensuel au détail qui le compose.
26. Suivre une prestation du premier contact à sa lecture financière
Un parcours traverse l’ERP historique puis retrouve ses données dans Phoenix
Un contact commercial devient client. Ses interlocuteurs sont enregistrés et les premières activités qualifient les appels, notes, rendez-vous ou tâches à poursuivre. Un projet est créé selon la nature de la prestation attendue.
Pour un web package, l’équipe choisit une offre, ajuste modules, options et lignes standards, puis génère le devis. Pour une prestation libre, elle utilise le parcours documentaire correspondant. La timeline peut détailler itérations et actions de livraison.
Le projet donne ensuite lieu à une facture. Le règlement rejoint la catégorie commerciale concernée ; les charges, notes et frais rattachés complètent la lecture de l’activité. Les documents restent accessibles depuis leur contexte.
Lors de la refondation Phoenix, client, devis, facture et lignes sont repris par leurs commandes dédiées. Les références de migration maintiennent leur provenance ; les montants réglés, impayés, charges et encaissements alimentent ensuite la vue mensuelle du nouveau back-office.
27. Continuer la refonte par domaines plutôt que par écrans
Le patrimoine de la première génération sert de carte, pas de cahier de copie
Phoenix établit le noyau financier et la mécanique de migration. La suite naturelle consiste à choisir les domaines de l’ancien ERP dont la valeur reste actuelle : activité client, gestion de projet, timelines, catalogue d’offres, production documentaire ou hébergement.
Chaque reprise doit définir ses invariants avant de déplacer ses écrans. Pour les projets, il faut préserver les types et relations ; pour les documents, les lignes et calculs ; pour les activités, le rattachement, le type et la prochaine action.
Une refonte de back-office métier peut progresser par lots : importer les données, vérifier la parité du parcours, ouvrir la nouvelle vue puis retirer l’ancien périmètre lorsque ses responsabilités ont changé de propriétaire.
Dawap ERP constitue une preuve double : la capacité à modéliser une exploitation complète et la capacité à reprendre ses données dans un socle plus étroit. Ces deux compétences comptent lorsqu’un logiciel interne doit évoluer sans perdre son histoire.
28. Conclusion
Pourquoi ce projet donne envie de travailler avec Dawap
Entre avril 2017 et novembre 2019, Dawap ERP construit un back-office dense où clients, projets, actions, offres, devis, factures, dépenses, timelines et hébergement conservent leurs relations. Sa singularité vient de cette couverture opérationnelle précise, pas d’une promesse générique de centralisation.
Phoenix ouvre ensuite une autre manière de faire évoluer le produit. Le compte devient la frontière, le noyau financier est reconstruit, sept commandes reprennent les données historiques et l’API fournit au back-office les ressources nécessaires à la lecture comptable.
Ce parcours montre qu’une refonte de logiciel métier réussie commence par ce qui doit rester vrai après la migration : l’identité des données, les règles des documents, la séparation des rôles et la possibilité de relire chaque agrégat depuis ses sources.
