Portail web softia

Refonte SI : Pourquoi choisir le Low-Code Meta-data Driven ?

admin_softia — Tue, 24 Mar 2026 14:22:59 +0000

Pourquoi l’architecture "Low Code Meta-data Driven" Open Source est le futur du développement de SI métier

Le dilemme du « Build vs Buy » vit ses dernières heures. Alors que les entreprises exigent une agilité sans précédent, les DSI se retrouvent coincés entre des ERP monolithiques trop rigides et des développements spécifiques sur frameworks classiques qui génèrent une dette technique exponentielle. Et si la solution ne résidait pas dans un nouvel outil, mais dans un changement de paradigme architectural alliant la puissance des méta-données, la liberté de l’Open Source et une interopérabilité totale prête pour l’IA ?

L'impasse des approches traditionnelles : un héritage trop lourd

Comparaison des approches : Build vs Buy vs Low-Code Open Source

Critère	ERP Standard (Buy)	Framework classique (Build)	Low-Code Meta-data Driven OS
Coût de licence	Élevé – par user/module	Nul	Nul – License Free
Agilité métier	Faible – rigidité éditeur	Totale mais coûteuse	Élevée – config + code
Time-to-Market	Moyen	Long	÷ 3 grâce aux méta-données
Dette technique	Dépendance éditeur	Exponentielle	Faible – socle séparé du métier
Interopérabilité API	Partielle – connecteurs payants	À développer	Native – Full API REST
IA-Ready	Difficile – données en silos	Possible mais complexe	Natif – données structurées
Souveraineté	Vendor lock-in	Totale	Totale – code source ouvert
Recrutement	Profils rares et coûteux	Standard mais code spécifique	Framework normalisé mondial

La colonne Low-Code Meta-data Driven Open Source correspond à l’approche Frappe / ERPNext mise en œuvre par Softia.

Pour tout DSI, la refonte du Système d’Information (S.I.) est un exercice d’équilibriste de haute voltige. D’un côté, l’achat d’un ERP standard promet une structure et une sécurité rassurantes, mais se heurte vite au mur de la réalité métier. Dès qu’un processus sort du cadre prévu par l’éditeur, les coûts d’adaptation explosent. Pire encore, le modèle de licence par utilisateur ou par module crée une friction budgétaire constante, limitant l’expansion du digital dans l’entreprise.

De l’autre, le développement spécifique sur des frameworks classiques (Symfony, Laravel, Django, Spring Java) offre une liberté totale, mais au prix d’une maintenance perpétuelle. Vous devenez l’otage d’un code « artisanal » où chaque mise à jour de sécurité devient un projet à risque.

En 2026, la question n’est plus de savoir quel logiciel choisir, mais comment construire une plateforme capable de muter au rythme de l’entreprise sans jamais aliéner sa liberté. C’est ici qu’intervient le Framework Low-Code Métier Open Source.

Le secret de la performance : l'architecture "Meta-data Driven"

Pourquoi certains frameworks permettent-ils de livrer des applications 3 à 5 fois plus vite ? La réponse tient dans les méta-données dynamiques.

Dans une architecture classique, le schéma de données, la logique métier et l’interface sont étroitement liés dans le code source. Dans une architecture Meta-data Driven (comme celle du framework Frappe), le framework agit comme un interpréteur. Vous définissez un « DocType » (un objet métier comme un « Contrat » ou un « Capteur IoT ») via des méta-données, et le moteur génère instantanément :

La table en base de données.
L’interface utilisateur (UI) réactive.
Le système de droits d’accès et d’audit.

Pour une DSI, c’est la fin du code redondant. On ne « développe » plus une fonction de recherche ou un filtre ; on les active par configuration.

L'interopérabilité au cœur : le paradigme "Full API"

Un S.I. moderne n’est plus une île. C’est un nœud au sein d’un écosystème complexe. L’un des arguments majeurs d’un framework basé sur les méta-données est sa capacité Full API native.

Puisque chaque objet métier (DocType) est défini de manière structurée, le framework génère automatiquement des points de terminaison (endpoints) RESTful pour chaque entité.

Intégration facilitée : Que vous deviez connecter votre S.I. à un outil de marketing automation, un logiciel de paie tiers ou des automates industriels, l’API est déjà là. Pas de code ad-hoc à écrire pour exposer vos données.
Architecture Headless : Vous pouvez utiliser le framework comme un « backend-as-a-service » pour alimenter des applications mobiles spécifiques ou des portails clients sur-mesure, tout en bénéficiant de la robustesse du moteur métier central.
Webhooks et Temps Réel : L’interconnexion ne se limite pas à la lecture : le système peut pousser des événements vers l’extérieur dès qu’une donnée change, garantissant une synchronisation parfaite de votre écosystème logiciel.

L'IA comme multiplicateur de force : de la donnée structurée à l'IA Métier

L’Intelligence Artificielle est la priorité de 2026, mais elle ne vaut que par la donnée qu’elle consomme. C’est ici que l’approche Meta-data Driven révèle son génie caché.

Parce que vos données sont rigoureusement structurées et documentées par les méta-données, elles deviennent « IA-Ready » par définition.

Agents autonomes et LLMs : Il est infiniment plus simple de brancher un agent IA (via RAG – Retrieval-Augmented Generation) sur une structure de méta-données claire que sur une base de données relationnelle obscure. L’IA « comprend » naturellement le contexte de vos processus.
Services d’IA intégrés : Imaginez un workflow où l’IA analyse automatiquement une pièce jointe, extrait les données via OCR, et remplit le DocType correspondant en suivant les règles de validation définies dans le framework.
Analyse prédictive : En intégrant des services de Machine Learning via l’API, votre S.I. passe du stade de gestionnaire de données à celui d’outil d’aide à la décision (prévision de stocks, détection de fraude, maintenance prédictive).

Souveraineté et liberté : la puissance de l'Open Source "License Free"

L’intégration de l’Open Source dans cette équation n’est pas un détail technique, c’est une décision de gouvernance stratégique.

Sortir du « Vendor Lock-in » : Avec une licence libre, le DSI reprend le contrôle. Si votre prestataire ne vous convient plus, vous changez. Si l’éditeur change sa politique tarifaire, vous n’êtes pas impacté. Vous possédez les clés du coffre : le code source, la base de données et la plateforme d’exécution.
L’auditabilité et la sécurité : L’Open Source signifie transparence. Contrairement aux « boîtes noires » propriétaires, le code peut être audité. La communauté mondiale agit comme un système immunitaire permanent, détectant et corrigeant les failles bien plus rapidement que n’importe quel support client privé.
Zéro coût de licence, 100% de valeur métier : Le modèle « License Free » déplace le centre de gravité budgétaire. Au lieu de payer des rentes annuelles pour le simple droit d’utiliser un outil, la DSI réalloue ce budget vers l’innovation. Chaque euro investi sert à créer des fonctionnalités spécifiques à votre métier.

Réduire la dette technique : le Graal du DSI

70% des budgets informatiques sont aujourd’hui absorbés par la maintenance du « Run ». L’approche par méta-données Open Source attaque ce problème à la racine :

Séparation du socle et du métier : La mise à jour du cœur du système ne « casse » pas vos développements spécifiques car ils résident dans la couche méta-données.
Standardisation native : En utilisant un framework mondialement reconnu, vous recrutez plus facilement. Un développeur sera opérationnel en quelques jours sur une architecture normalisée, là où il lui faudrait des mois pour comprendre un code propriétaire complexe.

Le ROI réel : une analyse sur 5 ans

TCO comparatif sur 5 ans

Poste de coût	ERP Standard	Framework classique	Low-Code OS (Frappe)
Année 1 – Build & Déploiement
Licences logicielles	Élevées	Nulles	Nulles
Charge de développement	Moyenne (paramétrage)	Très élevée	Réduite (÷ 2 à 3)
Time-to-Market	Moyen	Long	Court
Années 2 à 5 – Run & Évolution
Maintenance licences	Annuelle – obligatoire	Nulle	Nulle
Coût d’évolution métier	Élevé – dépendance éditeur	Élevé – dette technique	Faible – config méta-données
Intégration IA / SaaS tiers	Complexe et coûteuse	Développement spécifique	Native via Full API
Risque de rupture à la mise à jour	Modéré	Élevé	Faible – socle / métier séparés

Analyse qualitative basée sur les retours terrain et la structure architecturale des plateformes. Le TCO réel dépend du périmètre fonctionnel et du contexte de chaque organisation.

Si l’on compare le coût total de possession (TCO), l’avantage du Low-Code Open Source API-First est massif :

Année 1 (Build) : Time-to-Market divisé par 3 grâce au moteur Meta-data Driven. Absence de coûts de licences initiaux.
Années 2 à 5 (Run) : Pas de frais de maintenance liés aux licences. Intégration simplifiée de nouveaux services (IA, SaaS tiers) grâce à l’API native. Évolutivité sans surcoût.

Conclusion : un choix de visionnaire pour 2026

La refonte d’un S.I. ne doit plus être vue comme un projet « Big Bang » douloureux, mais comme la mise en place d’un organisme vivant, communicant et intelligent. Pour réussir ce défi, les DSI doivent délaisser les solutions rigides pour adopter des plateformes de composition métier.

L’alliance de l’architecture Meta-data Driven, de l’Open Source et du Full API est la seule capable de répondre au triple impératif de la DSI moderne : Vitesse de livraison, Souveraineté totale et Intelligence embarquée.

En choisissant une solution « License Free » et ouverte, vous n’achetez pas seulement un outil, vous investissez dans un actif numérique durable qui appartient réellement à votre entreprise. C’est le passage d’une informatique de consommation à une informatique de construction et d’innovation.

Prêt à repenser l'architecture de votre SI ?

Ne laissez plus la dette technique ou les licences brider votre croissance. Nos experts Softia vous accompagnent pour évaluer la pertinence d’une architecture Low-Code Meta-data Driven (Frappe / ERPNext) sur votre périmètre.

FAQ

Q1 : Qu'est ce qu'un architecture "Meta-data Driven" concrètement ?

ERPNext, le « WordPress des processus métier »… avec la rigueur d’un ERP

admin_softia — Thu, 05 Mar 2026 10:44:41 +0000

ERPNext, le "WordPress des processus métier"… avec la rigueur d'un ERP

Il y a une comparaison qui revient de plus en plus souvent chez les équipes projet : « ERPNext, c’est le WordPress des processus métier (mais avec la rigueur d’un ERP). » La formule fait sourire, mais elle dit quelque chose de très concret pour les décideurs, chefs de projets et DSI : la promesse de déployer vite une solution de gestion adaptée au réel de l’entreprise, sans reconstruire un ERP depuis zéro ni tomber dans l’usine à gaz des développements lourds.

Cette analogie ne signifie pas qu’ERPNext serait un « outil simple » au sens réducteur du terme. Elle souligne un point clef : Frappe, la plateforme sur laquelle ERPNext est construit, adopte une approche meta-driven, pilotée par les métadonnées, qui rapproche l’expérience de construction applicative de ce que le CMS a apporté au web : modéliser, configurer, publier, faire évoluer. Avec, en plus, la discipline attendue d’un système transactionnel.

Quand l'ERP standard ne colle pas au terrain

Or l’offre se polarise souvent entre deux extrêmes. D’un côté, le progiciel très riche mais exigeant : paramétrage complexe, compétences rares, surcouches multiples, délais. De l’autre, le développement sur mesure, parfaitement ajusté, mais souvent coûteux à maintenir, dépendant des équipes, et long à stabiliser, surtout si l’on réinvente des briques transverses : sécurité, droits, workflows, audit, reporting, API.

ERPNext vient occuper une zone intéressante entre ces deux pôles : un socle ERP complet (comptabilité, ventes, achats, stock, projets, RH selon modules) combiné à une plateforme applicative permettant de construire des extensions et applications métier cohérentes, industrialisées et maintenables.

Le "WordPress effect" appliqué aux processus

Pourquoi la comparaison avec WordPress tient-elle ? Parce que Frappe/ERPNext permet de construire des objets métier et des écrans par assemblage de composants standard, comme un CMS le fait avec des types de contenu. Cinq mécanismes structurants en sont le moteur.

Le modèle métier déclaratif (DocTypes) est le premier. Dans Frappe, un objet métier, Client, Demande d’Achat, Fiche d’Intervention, Non-conformité, se définit comme un « type » : champs, relations, contraintes, listes, formulaires. L’interface utilisateur se génère naturellement autour de ce modèle, sans développement d’écran.

Les règles d’accès et rôles viennent ensuite. Les permissions sont gérées au niveau des objets et des actions (lecture, écriture, soumission, annulation), avec des mécanismes pour segmenter par entité, périmètre, établissement, équipe ou niveau de responsabilité. Troisième levier : les workflows et statuts. Validation, rejet, escalade, circuits multi-niveaux, les workflows deviennent des composants configurables, et non des développements cachés dans du code.

Quand la configuration atteint ses limites, Frappe propose des mécanismes d’extension, scripts, hooks, règles métier, qui permettent d’aller au-delà tout en restant dans un cadre outillé et documenté. Enfin, le reporting et les impressions sont natifs : rapports, tableaux de bord, exports, formats d’impression, l’écosystème pousse à produire rapidement des sorties opérationnelles sans multiplier les outils externes.

L’effet est bien connu des équipes : on passe d’un mode « spécifications → dev → recette » sur chaque détail à un mode « prototype → configuration → itérations courtes ». Le projet devient plus démonstratif, plus agile, et souvent plus acceptable pour les métiers, qui voient l’outil se construire sous leurs yeux.

Une rigueur d'ERP… et pas un simple outil de formulaires

Là où l’analogie s’arrête, c’est sur la nature des données. Un CMS gère du contenu. Un ERP gère des transactions : écritures comptables, valorisation, mouvements de stock, engagements, traçabilité, auditabilité. ERPNext apporte donc des fondations que des solutions « BPM + formulaires » n’offrent pas toujours.

L’intégrité des référentiels, articles, clients, fournisseurs, nomenclatures, projets, est garantie par le modèle. La traçabilité (qui a fait quoi, quand, sur quel document) est native. Le chaînage des opérations est structurel : devis → commande → livraison → facture, achat → réception → facture fournisseur. Les contraintes de gestion (états, validations, règles de cohérence) et l’ouverture technique (API, intégrations, connecteurs) complètent ce socle.

C’est précisément ce qui rend le couple Frappe/ERPNext attractif : la capacité à construire du spécifique sans perdre la solidité transactionnelle.

Trois cas d'usage où l'approche se matérialise

Ces mécanismes ne sont pas abstraits. Voici comment ils se traduisent sur des processus concrets.

Circuit de validation "Client à valider"

Une organisation souhaite encadrer l’ouverture de comptes clients : collecte de pièces, conformité, validation commerciale, validation finance, puis activation. Avec ERPNext/Frappe, on ajoute les champs nécessaires (statut, pièces, scoring, commentaires), on définit un workflow multi-étapes, on restreint les droits selon le rôle, on automatise les notifications, et on génère un tableau de suivi des dossiers en cours. Ce qui aurait nécessité un développement spécifique devient une configuration.

"Ordre de fabrication à contrôler" (qualité/production)

Dans un contexte industriel, le processus n’est pas seulement de produire, mais de contrôler : points qualité, non-conformités, dérogations, libération. On structure une fiche de contrôle liée à l’OF, des statuts (à contrôler / contrôlé / bloqué / libéré), des règles d’alerte et d’escalade, et une traçabilité exploitable en audit. La plateforme absorbe cette complexité sans développement ad hoc.

Maintenance et interventions terrain

Mise en œuvre : ce qui rend le démarrage rapide (et ce qui doit rester cadré)

La rapidité de démarrage ne vient pas d’un « bouton magique ». Elle vient d’une méthode qui exploite intelligemment le socle. Le cadrage orienté processus est le point de départ : on cartographie les étapes, acteurs, objets, décisions, contrôles, et on distingue ce qui relève du paramétrage de ce qui nécessite du spécifique.

On construit ensuite un prototype rapide, une première version fonctionnelle (écrans, champs, workflow) — très tôt dans le projet, pour verrouiller l’adhésion et réduire l’ambiguïté. Les itérations courtes suivent : ajustements par cycles sur l’ergonomie, les règles, les états, les rapports, les droits. L’intégration et la migration des données se font en parallèle, de manière progressive et contrôlée via API et flux. La conduite du changement, formation ciblée, référents métiers, pilotage par l’usage, KPI d’adoption, clôt le dispositif.

Le point d’attention principal : la tentation de « tout faire tout de suite ». Comme avec un CMS, la facilité de création peut encourager l’empilement. Le succès dépend d’une gouvernance claire : nomenclature, règles de nommage, logique d’habilitation, documentation légère, stratégie de versioning.

Softia : du sur-mesure industriel sur un socle standard

Dans ce paysage, Softia se positionne avec une proposition lisible : le développement sur mesure et l’intégration de solutions spécifiques, adossés à un socle robuste (Frappe/ERPNext), plutôt que de reconstruire les fondations à chaque projet.

Cette trajectoire n’est pas anodine. Maîtriser « depuis le mainframe jusqu’aux architectures web distribuées » donne une culture de l’industrialisation et de la qualité. Appliquée à Frappe/ERPNext, elle se traduit par une approche pragmatique : exploiter au maximum le standard ERPNext, n’ajouter du spécifique que là où il crée un avantage métier réel, intégrer proprement (API, échanges, sécurité), livrer une solution maintenable (documentation, tests, outillage, méthode). Aller vite, oui, mais vite et durable.

La bonne question à se poser

Qualifier ERPNext de « CMS de l’ERP » n’est pas un slogan gratuit. C’est une façon de reformuler un critère de choix devenu central : à quel point pourra-t-on faire évoluer le système au rythme du métier, sans dépendre d’un tunnel de développements ?

Si l’organisation a des processus spécifiques, une exigence de traçabilité, et une volonté de maîtriser ses coûts et ses délais, alors ERPNext/Frappe mérite d’être évalué, non pas comme un ERP « de plus », mais comme une plateforme ERP + low-code capable de produire rapidement des solutions opérationnelles, tout en gardant la discipline attendue d’un système transactionnel.

Et c’est exactement là que la comparaison fonctionne : comme WordPress a démocratisé la publication web sans sacrifier l’industrialisation, ERPNext démocratise une partie de la construction applicative métier… sans renoncer à la rigueur d’un ERP.

Vous voulez voir ce que ça donne sur vos propres processus ?

Plutôt qu’un discours, nous préférons montrer. En 72 heures, nous construisons un prototype fonctionnel basé sur vos flux réels, sans engagement de votre part.

Vos questions, nos réponses d'expert

Q1 : En quoi ERPNext est-il comparable à WordPress ?

ERPNext, le « WordPress des processus métier »… avec la rigueur d’un ERP

admin_softia — Tue, 03 Mar 2026 09:04:13 +0000

ERPNext, le "WordPress des processus métier"… avec la rigueur d'un ERP

Cette analogie ne signifie pas qu’ERPNext serait un « outil simple » au sens réducteur du terme. Elle souligne un point clef : Frappe, la plateforme sur laquelle ERPNext est construit, adopte une approche meta-driven pilotée par les métadonnées qui rapproche l’expérience de construction applicative de ce que le CMS a apporté au web : modéliser, configurer, publier, faire évoluer. Avec, en plus, la discipline attendue d’un système transactionnel.

Quand l'ERP standard ne suit plus le rythme de l'entreprise

Dans beaucoup d’organisations, l’enjeu n’est plus seulement « d’avoir un ERP ». Il est de faire vivre des processus spécifiques : circuits de validation, contrôles qualité, suivi d’intervention, conformité, traçabilité, gestion d’actifs, gestion d’affaires, intégration avec des outils existants, reporting adapté, interfaces sur mesure. Or l’offre se polarise souvent entre deux extrêmes. D’un côté, le progiciel très riche mais exigeant : paramétrage complexe, compétences rares, surcouches multiples, délais. De l’autre, le développement sur mesure, parfaitement ajusté, mais souvent coûteux à maintenir, dépendant des équipes, et long à stabiliser, surtout si l’on réinvente des briques transverses : sécurité, droits, workflows, audit, reporting, API. ERPNext vient occuper une zone intéressante entre ces deux pôles : un socle ERP complet (comptabilité, ventes, achats, stock, projets, RH selon modules) combiné à une plateforme applicative permettant de construire des extensions et applications métier cohérentes, industrialisées et maintenables.

Critère	Le Paquebot (progiciel lourd)	La Formule 1 (dev sur-mesure)	ERPNext / Frappe
Délai de déploiement	6 à 18 mois	12 à 36 mois	8 à 12 semaines (MVP) ✓
Adaptation aux processus	Vous adaptez vos processus à l’outil	Outil 100% adapté, mais figé	Outil adapté à vos processus, évolutif ✓
Coût de maintenance	Licences + consultants coûteux	Dépendance aux développeurs ✗	Open source, TCO maîtrisé ✓
Évolutivité	Lente, coûteuse	Très coûteuse	Par configuration, sans dev lourd ✓
Indépendance éditeur	Forte dépendance ✗	Dépendance à l’équipe dev ✗	Open source, code ouvert ✓

Comparaison indicative, chaque projet est unique

L'effet « WordPress » appliqué à vos processus

Le modèle métier déclaratif (DocTypes) est le premier. Dans Frappe, un objet métier — Client, Demande d’Achat, Fiche d’Intervention, Non-conformité — se définit comme un « type » : champs, relations, contraintes, listes, formulaires. L’interface utilisateur se génère naturellement autour de ce modèle, sans développement d’écran.

Les règles d’accès et rôles viennent ensuite. Les permissions sont gérées au niveau des objets et des actions (lecture, écriture, soumission, annulation), avec des mécanismes pour segmenter par entité, périmètre, établissement, équipe ou niveau de responsabilité. Troisième levier : les workflows et statuts. Validation, rejet, escalade, circuits multi-niveaux — les workflows deviennent des composants configurables, et non des développements cachés dans du code.

Quand la configuration atteint ses limites, Frappe propose des mécanismes d’extension, scripts, hooks, règles métier qui permettent d’aller au-delà tout en restant dans un cadre outillé et documenté. Enfin, le reporting et les impressions sont natifs : rapports, tableaux de bord, exports, formats d’impression — l’écosystème pousse à produire rapidement des sorties opérationnelles sans multiplier les outils externes.

Capacité	Ce que ça permet concrètement	Exemple d’usage
Objets métier configurables	Créer des formulaires et des fiches sans coder	Fiche client avec champs spécifiques, score de risque
Droits d’accès par rôle	Définir qui voit quoi, qui valide quoi	Le commercial ne peut pas valider la partie finance
Workflows visuels	Configurer des circuits de validation sans développement	Validation devis → Commande → Livraison → Facture
Scripts et hooks	Aller plus loin quand la configuration ne suffit pas	Calcul automatique d’un prix selon des règles métier
Reporting intégré	Produire des rapports opérationnels sans outil externe	Tableau de bord des dossiers clients en cours

Fonctionnalités natives de la plateforme Frappe/ERPNext

Une rigueur d'ERP… et pas un simple outil de formulaires

L’intégrité des référentiels, articles, clients, fournisseurs, nomenclatures, projets est garantie par le modèle. La traçabilité (qui a fait quoi, quand, sur quel document) est native. Le chaînage des opérations est structurel : devis → commande → livraison → facture, achat → réception → facture fournisseur. Les contraintes de gestion (états, validations, règles de cohérence) et l’ouverture technique (API, intégrations, connecteurs) complètent ce socle.

C’est précisément ce qui rend le couple Frappe/ERPNext attractif : la capacité à construire du spécifique sans perdre la solidité transactionnelle.

Trois cas d'usage où l'approche se matérialise

Ces mécanismes ne sont pas abstraits. Voici comment ils se traduisent sur des processus concrets.

Circuit de validation "Client à valider"

Ordre de fabrication à contrôler" (qualité/production)

Maintenance et interventions terrain

ERPNext sert de socle (clients, contrats, facturation) ; Frappe permet d’ajouter la couche opérationnelle : typologie d’intervention, checklist, photos, signatures, workflow de validation, reporting opérationnel (SLA, délais, taux de réouverture). Le tout reste cohérent avec le référentiel central, sans silo applicatif supplémentaire.

Mise en œuvre : ce qui rend le démarrage rapide (et ce qui doit rester cadré)

On construit ensuite un prototype rapide, une première version fonctionnelle (écrans, champs, workflow), très tôt dans le projet, pour verrouiller l’adhésion et réduire l’ambiguïté. Les itérations courtes suivent : ajustements par cycles sur l’ergonomie, les règles, les états, les rapports, les droits. L’intégration et la migration des données se font en parallèle, de manière progressive et contrôlée via API et flux. La conduite du changement, formation ciblée, référents métiers, pilotage par l’usage, KPI d’adoption, clôt le dispositif.

Softia : du sur-mesure industriel sur un socle standard

La bonne question à se poser

The post ERPNext, le « WordPress des processus métier »… avec la rigueur d’un ERP appeared first on Portail web softia.