les étapes du projet
Une modernisation du SI au service de la performance opérationnelle
Dans le cadre de sa stratégie de dynamisation de son système d’information, Orchestra a confié à toHero le développement de deux applications métier interconnectées à son ERP et à son OMS. L’objectif était clair : augmenter la productivité des équipes opérationnelles, tout en repensant l’architecture logicielle pour garantir stabilité, maintenabilité et évolutivité dans le temps. Ces projets s’inscrivent dans une volonté de simplification des processus internes et de réduction des tâches manuelles à faible valeur ajoutée.
Une architecture cloud modulaire et scalable
Les équipes toHero ont conçu une architecture inspirée de la MACH Approach (Microservices, API-first, Component, Headless).
Cette approche permet de découpler les composants métier et techniques, de faciliter l’évolution des applications et d’assurer une forte robustesse du système dans un environnement à forte volumétrie.
Des outils métier centrés sur les usages internes
BaseDog – Commandes fournisseurs
BaseDog permet de gérer l’ensemble du cycle de vie des commandes fournisseurs textiles : création, modification, annulation et contrôle des prix d’achat, en lien direct avec les entrepôts et les collections.
VPM – Vendors & Products
L’outil VPM centralise la création et la gestion des fournisseurs, agents et usines, ainsi que la gestion des articles et des données nécessaires à l’étiquetage des produits.
Ces plateformes facilitent la gestion simultanée de multiples sources de données et fiabilisent les flux métier.
Un projet mené dans un environnement complexe
Le SI d’un groupe comme Orchestra repose sur des processus, des workflows et des règles métiers hétérogènes, parfois variables selon les pays. La multiplicité des bases de données, des partenaires et des prestataires a nécessité un cadrage rigoureux et une forte exigence en matière de stabilité, de sécurité et de scalabilité.
Le résultat
Le développement des deux application métiers pour Orchestra a permis de :
- Réduction du temps de création d’une commande fournisseur, passé de 30 minutes à 1 heure à quelques minutes, grâce à un formulaire dynamique intelligent.
- Centralisation et agrégation automatique de données issues de plusieurs systèmes (ERP, OMS et bases métiers).
- Diminution significative des erreurs lors de la création des commandes fournisseurs.
- Automatisation et simplification de tâches métier historiquement chronophages.
- Gain de productivité pouvant atteindre 60 % sur certaines tâches récurrentes.
- Amélioration de la fiabilité, de la maintenabilité et de l’évolutivité du système d’information.
« C’est un réel plaisir de collaborer avec toHero, un sentiment partagé par l’équipe métier. Je suis très fière de l’équipe que j’ai aujourd’hui. Un grand merci à eux : je n’aurais pas pu y arriver seule ! Leur soutien a été essentiel dans cette réussite. »
Hélène Avenel
Orchestra en images
Mockups et illustrations du projet
Donner vie au concept à travers le design
FAQ
En quoi consiste le design thinking appliqué au développement logiciel ?
Le design thinking est une approche de conception centrée sur les usages réels des utilisateurs. Appliqué au développement logiciel, il inverse l’ordre classique des décisions. Ainsi, on part des besoins, des frustrations et des comportements terrain avant de définir les fonctionnalités à développer. Résultat : le produit conçu et construit est utilisé par la cible d’utilisateurs.
Qu’est qu’un minimum lovable product ?
Le Minimum Lovable Product est la version minimale d’un produit conçu pour maximiser l’adoption et le repeat. Cette technique se base sur ce qui crée réellement l’attachement et l’adoption dès la première utilisation. Contrairement au MVP (minimum viable product), il priorise la valeur perçue plutôt que la valeur fonctionnelle.
Quelle est la différence entre un MVP et un minimum lovable product ?
Le MVP vise la version minimale livrable et fonctionnelle d’un produit dans le cycle de développement. De son côté le MLP vise la version minimale que les utilisateurs aimeront et voudront adopter dans leurs quotidien. L’enveloppe budgétaire peut être similaire entre les deux approches mais la priorisation du backlog est fondamentalement différente dès le cadrage.
Pourquoi le Design Driven Development est indispensable pour livrer un MLP ?
Sans prototypage et recherche utilisateur réalisés en amont du cycle développement, un MLP reste une simple intention. Le DDD constitue l’infrastructureméthodologique qui garantit que les décisions d’adoption précèdent bien les décisions de développement, du maquettage jusqu’au handoff.
Le Minimum Lovable Product coûte-t-il plus cher que le MVP ?
Il réalloue le budget différemment. Les quick wins d’attachement sont souvent des investissements modestes à fort impact sur l’attachement. McKinsey, le mesure : + 32 % de croissance de revenus sur cinq ans sont possible pour les entreprises design-driven vis à vis de leurs pairs.
Le Design Driven Development s’applique-t-il toujours aux projets de modernisation SI ou d’ERP ?
Oui, et c’est d’ailleurs là que l’enjeu adoption est le plus fort. Les utilisateurs ont des habitudes établies et le droit de contourner une solution ou un outil. Le DDD permet d’identifier les quick winsd’attachement qui réduisent ce risque dès le cadrage, du maquettage jusqu’à l’itération finale.
