19/03/2025
A lire avant de cliquer sur son icône Mercator ERP et tellement vrai qu'on n'y pense plus après 👍
[ ]
Depuis la version 1.0 de Mercator, l’objectif de l’équipe de développement a toujours été d’assurer une transition fluide entre les différentes versions, sans rupture brutale pour les utilisateurs. 🎯
Il nous parait impensable que nos clients perdent leur investissement au gré des mises à jour de Mercator ou éprouvent des difficultés liées à celles-ci. Alors, comment procédons-nous ❓
𝗟𝗮 𝘀𝘁𝗿𝗮𝘁𝗲́𝗴𝗶𝗲 𝗱𝗲 𝘃𝗲𝗿𝘀𝗶𝗼𝗻𝗶𝗻𝗴 – 𝗴𝗲𝘀𝘁𝗶𝗼𝗻 𝗱𝗲𝘀 𝘃𝗲𝗿𝘀𝗶𝗼𝗻𝘀
L’évolution du logiciel Mercator est quotidienne. Nous ne cessons jamais d’ajouter des fonctionnalités et d’en modifier d’autres. Les fonctionnalités liées à une version sont distillées au fur et mesure. La stratégie est donc celle d’une pente douce.
Ce mode de distribution permanente offre de nombreux avantages :
Il n’est pas nécessaire d’attendre un changement de version pour obtenir, en une seule fois, un lot conséquent de fonctionnalités. Elles arrivent dès qu’elles sont prêtes.
Dès lors, il n’y a jamais de grosse rupture entre les versions. Cela réduit le risque de bugs lors de la mise à jour.
Même si des fonctionnalités majeures sont libérées à partir d’une certaine version, l’équipe de développement travaille toujours sur un seul exécutable.
L’avantage pour les utilisateurs est qu’il n’est pas nécessaire d’attendre la version suivante pour qu’un bug soit corrigé. Les correctifs sont déployés gratuitement dans l’unique exécutable utilisé par tous nos clients. La modification / correction à un seul endroit rend le développement plus efficace et donc plus rapide : la plupart du temps, en quelques heures ou dans la journée.
𝗠𝗲𝗿𝗰𝗮𝘁𝗼𝗿 𝗲́𝘃𝗼𝗹𝘂𝗲 𝗺𝗮𝗶𝘀 𝗹𝗮 𝗰𝗼𝗺𝗽𝗮𝘁𝗶𝗯𝗶𝗹𝗶𝘁𝗲́ 𝗮𝘀𝗰𝗲𝗻𝗱𝗮𝗻𝘁𝗲 𝗲𝘀𝘁 𝗮𝘀𝘀𝘂𝗿𝗲́𝗲
Fréquemment, de nouvelles options sont ajoutées dans le standard de Mercator pour répondre à des besoins métiers supplémentaires.
Lors de l’ajout d’une option, l’équipe de développement veille à ce que la valeur par défaut de celle-ci corresponde au comportement qui prévalait avant la mise à jour. Ainsi :
▶️ L’utilisateur qui n’est pas concerné par cette option n’a aucune action à réaliser et continue d’utiliser son ERP à l’identique.
▶️ Et l’utilisateur qui attend cette nouvelle fonctionnalité peut simplement l’activer selon son choix.
𝗟𝗲𝘀 𝗽𝗲𝗿𝘀𝗼𝗻𝗻𝗮𝗹𝗶𝘀𝗮𝘁𝗶𝗼𝗻𝘀 𝗱𝗲 𝗰𝗵𝗮𝗾𝘂𝗲 𝗰𝗹𝗶𝗲𝗻𝘁 𝘀𝗼𝗻𝘁 𝗺𝗮𝗶𝗻𝘁𝗲𝗻𝘂𝗲𝘀, 𝗮̀ 𝗰𝗵𝗮𝗾𝘂𝗲 𝗺𝗶𝘀𝗲 𝗮̀ 𝗷𝗼𝘂𝗿
Mercator ERP n’est pas un programme « open source ». Et c’est un avantage pour nos utilisateurs.
Dans un ERP « open-source », les modifications de comportement du logiciel et l’ajout de fonctionnalités sont effectuées directement dans le code de l’application. Ces modifications seront perdues lors de l’installation d’une mise à jour.
Pour pallier à ça, les développeurs adoptent une stratégie modulaire : le code sur-mesure est placé dans des modules séparés qui ne seront pas nécessairement affectés par une mise à jour.
Certes, c’est mieux. Mais il restera toujours un travail à faire : s’assurer que ces modules séparés peuvent être « rebranchés » sur la nouvelle version du cœur. Cela implique des migrations et du testing, à chaque mise à jour. Et donc un coût non négligeable, voire même une indisponibilité de certaines fonctionnalités, le temps de les retravailler.
Dans Mercator, cette stratégie modulaire est prévue depuis la 1ière ligne de code. Les modules sur-mesure s’imbriquent sur des points d’appels qui, eux, ne seront jamais modifiés. En d’autres termes, une mise à jour du cœur de l’application n’impactera jamais les points de branchement des modules.
On compte plusieurs milliers de points de branchement entre le cœur et le code sur-mesure.
𝑃𝑜𝑢𝑟 𝑙𝑒𝑠 𝑝𝑙𝑢𝑠 𝑡𝑒𝑐ℎ𝑛𝑖𝑞𝑢𝑒𝑠 𝑑𝑒 𝑛𝑜𝑠 𝑙𝑒𝑐𝑡𝑒𝑢𝑟𝑠, 𝑐𝑒𝑠 𝑝𝑜𝑖𝑛𝑡𝑠 𝑠𝑜𝑛𝑡 𝑑𝑒́𝑓𝑖𝑛𝑖𝑠 𝑑𝑎𝑛𝑠 𝑑𝑒𝑠 𝑖𝑛𝑡𝑒𝑟𝑓𝑎𝑐𝑒𝑠 𝑝𝑢𝑏𝑙𝑖𝑞𝑢𝑒𝑠 𝑜𝑢 𝑑𝑒𝑠 𝑒́𝑣𝑒́𝑛𝑒𝑚𝑒𝑛𝑡𝑠 𝑝𝑢𝑏𝑙𝑖𝑐𝑠. 𝐿𝑎 𝑝𝑙𝑎𝑡𝑒𝑓𝑜𝑟𝑚𝑒 .𝑛𝑒𝑡 𝑚𝑒𝑡 𝑎̀ 𝑑𝑖𝑠𝑝𝑜𝑠𝑖𝑡𝑖𝑜𝑛 𝑙𝑒 𝑛𝑒́𝑐𝑒𝑠𝑠𝑎𝑖𝑟𝑒 𝑝𝑜𝑢𝑟 𝑏𝑖𝑒𝑛 𝑠𝑒́𝑝𝑎𝑟𝑒𝑟 𝑐𝑒𝑠 𝑑𝑒𝑢𝑥 𝑟𝑒́𝑎𝑙𝑖𝑡𝑒́𝑠. 𝐿’𝑒́𝑞𝑢𝑖𝑝𝑒 𝑑𝑒 𝑑𝑒́𝑣𝑒𝑙𝑜𝑝𝑝𝑒𝑚𝑒𝑛𝑡 𝑣𝑒𝑖𝑙𝑙𝑒 𝑎̀ 𝑐𝑒 𝑞𝑢𝑒, 𝑎𝑢 𝑔𝑟𝑒́ 𝑑𝑒𝑠 𝑣𝑒𝑟𝑠𝑖𝑜𝑛𝑠, 𝑐𝑒 𝑞𝑢𝑖 𝑒𝑠𝑡 « 𝑝𝑢𝑏𝑙𝑖𝑐 » (𝑎𝑢 𝑠𝑒𝑛𝑠 𝑑𝑒 𝑙𝑎 𝑝𝑟𝑜𝑔𝑟𝑎𝑚𝑚𝑎𝑡𝑖𝑜𝑛 𝑜𝑏𝑗𝑒𝑡) 𝑟𝑒𝑠𝑡𝑒 𝑖𝑛𝑐ℎ𝑎𝑛𝑔𝑒́. 𝐿𝑒 𝑓𝑟𝑎𝑚𝑒𝑤𝑜𝑟𝑘 .𝑛𝑒𝑡 𝑐𝑜𝑛𝑡𝑖𝑒𝑛𝑡 𝑡𝑜𝑢𝑡 𝑐𝑒 𝑞𝑢’𝑖𝑙 𝑓𝑎𝑢𝑡 𝑝𝑜𝑢𝑟 𝑒𝑛𝑟𝑖𝑐ℎ𝑖𝑟 𝑙’𝐴𝑃𝐼 𝑑𝑒 𝑀𝑒𝑟𝑐𝑎𝑡𝑜𝑟 𝑠𝑎𝑛𝑠 𝑗𝑎𝑚𝑎𝑖𝑠 𝑏𝑟𝑖𝑠𝑒𝑟 𝑙𝑎 𝑟𝑒́𝑡𝑟𝑜𝑐𝑜𝑚𝑝𝑎𝑡𝑖𝑏𝑖𝑙𝑖𝑡𝑒́ :
▶️ 𝐴𝑗𝑜𝑢𝑡 𝑑𝑒 𝑠𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒𝑠 𝑠𝑢𝑟 𝑙𝑒𝑠 𝑚𝑒́𝑡ℎ𝑜𝑑𝑒𝑠 𝑒𝑥𝑖𝑠𝑡𝑎𝑛𝑡𝑒𝑠 𝑎𝑓𝑖𝑛 𝑑’𝑎𝑢𝑔𝑚𝑒𝑛𝑡𝑒𝑟 𝑙𝑒 𝑛𝑜𝑚𝑏𝑟𝑒 𝑑𝑒 𝑝𝑎𝑟𝑎𝑚𝑒̀𝑡𝑟𝑒 𝑝𝑎𝑠𝑠𝑒́𝑠.
▶️ 𝐴𝑗𝑜𝑢𝑡 𝑑𝑒 𝑝𝑟𝑜𝑝𝑟𝑖𝑒́𝑡𝑒́𝑠 𝑝𝑢𝑏𝑙𝑖𝑞𝑢𝑒𝑠 𝑑𝑎𝑛𝑠 𝑙𝑒𝑠 𝑐𝑙𝑎𝑠𝑠𝑒𝑠 𝑝𝑢𝑏𝑙𝑖𝑞𝑢𝑒𝑠 𝑑𝑒 𝑀𝑒𝑟𝑐𝑎𝑡𝑜𝑟.
Cette architecture native du logiciel permet donc d’assurer une compatibilité ascendante, même en ce qui concerne les développements sur-mesure.
𝗟𝗮 𝗯𝗮𝘀𝗲 𝗱𝗲 𝗱𝗼𝗻𝗻𝗲́𝗲𝘀 𝘀’𝗮𝗱𝗮𝗽𝘁𝗲 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗾𝘂𝗲𝗺𝗲𝗻𝘁, 𝗮𝘂 𝗴𝗿𝗲́ 𝗱𝗲𝘀 𝘃𝗲𝗿𝘀𝗶𝗼𝗻
Nul besoin de scripts de migration de données lors d’une mise à jour de Mercator. Lors de son démarrage, le logiciel veille à ajouter les nouvelles colonnes ou ressources sur la base de données. Si nécessaire, les fonctions, procédures stockées et déclencheurs sont automatiquement mis à jour.
Lors de l'ajout d'un module standard au dossier, les nouvelles tables sont aussi automatiquement ajoutées à Mercator.
Ces opérations sont totalement invisibles pour l’utilisateur.
𝗟𝗲𝘀 𝗺𝗶𝘀𝗲𝘀 𝗮̀ 𝗷𝗼𝘂𝗿 𝘀𝗲 𝗱𝗲́𝗿𝗼𝘂𝗹𝗲𝗻𝘁 𝘀𝗮𝗻𝘀 𝗶𝗺𝗽𝗮𝗰𝘁
La plupart des utilisateurs Mercator bénéficient d’une mise à jour automatique effectuée la nuit. Les mises à jour de Mercator peuvent même être effectuées « à chaud », c’est-à-dire sans contraindre tous les utilisateurs à quitter le programme.
Que ça soit pour l’installation d’une mise à jour mineure ou majeure, le processus de mise à jour de Mercator est routinier, simple et même anodin.
➡️ 𝗘𝗻 𝗿𝗲́𝘀𝘂𝗺𝗲́, 𝗠𝗲𝗿𝗰𝗮𝘁𝗼𝗿 𝗽𝗿𝗼𝗽𝗼𝘀𝗲 𝘂𝗻 𝗺𝗼𝗱𝗲̀𝗹𝗲 𝗱𝗲 𝗺𝗶𝘀𝗲𝘀 𝗮̀ 𝗷𝗼𝘂𝗿 𝗳𝗹𝘂𝗶𝗱𝗲, 𝘀𝗮𝗻𝘀 𝗿𝘂𝗽𝘁𝘂𝗿𝗲 𝗲𝘁 𝘀𝗮𝗻𝘀 𝗰𝗼𝗻𝘁𝗿𝗮𝗶𝗻𝘁𝗲 𝗽𝗼𝘂𝗿 𝗹𝗲𝘀 𝘂𝘁𝗶𝗹𝗶𝘀𝗮𝘁𝗲𝘂𝗿𝘀. 𝗟’𝗼𝗯𝗷𝗲𝗰𝘁𝗶𝗳 𝗲𝘀𝘁 𝗱𝗲 𝗴𝗮𝗿𝗮𝗻𝘁𝗶𝗿 𝘂𝗻 𝗹𝗼𝗴𝗶𝗰𝗶𝗲𝗹 𝘁𝗼𝘂𝗷𝗼𝘂𝗿𝘀 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝘁, 𝗮̀ 𝗷𝗼𝘂𝗿 𝗺𝗮𝗶𝘀 𝗲́𝗴𝗮𝗹𝗲𝗺𝗲𝗻𝘁 𝗱𝗲 𝗽𝗿𝗼𝘁𝗲́𝗴𝗲𝗿 𝗹’𝗶𝗻𝘃𝗲𝘀𝘁𝗶𝘀𝘀𝗲𝗺𝗲𝗻𝘁 𝗱𝗲 𝗻𝗼𝘀 𝗰𝗹𝗶𝗲𝗻𝘁𝘀 💰 : 𝗹𝗮 𝗽𝗲𝗿𝘀𝗼𝗻𝗻𝗮𝗹𝗶𝘀𝗮𝘁𝗶𝗼𝗻 𝗱𝗲 𝗹𝗲𝘂𝗿 𝗹𝗼𝗴𝗶𝗰𝗶𝗲𝗹 𝗱𝗼𝗶𝘁 𝗲̂𝘁𝗿𝗲 𝘀𝗮𝘂𝘃𝗲𝗴𝗮𝗿𝗱𝗲́𝗲.
̀jour
