Se rendre au contenu
Baquedano Nathan Conseils
  • Se connecter
    • Accueil
    • Plans tarifaires
    • Articles
    • A propos de
    • Contactez-moi
  • ͏ +33 6 41 80 12 72 [email protected]


  • Contactez-moi
Baquedano Nathan Conseils
      • Accueil
      • Plans tarifaires
      • Articles
      • A propos de
      • Contactez-moi
    • ͏ +33 6 41 80 12 72 [email protected]


    • Se connecter
    • Contactez-moi
  • Articles
  • Comment j'ai construit un ERP de A à Z pour transformer une PME ?
  • Comment j'ai construit un ERP de A à Z pour transformer une PME ?

    Les étapes cruciales d'un projet de 6 mois, de l'immersion terrain au déploiement d'une solution sur-mesure.
    26 novembre 2025 par
    Comment j'ai construit un ERP de A à Z pour transformer une PME ?
    Baquedano Nathan Conseils, Nathan Baquedano

    L'entreprise où j'ai évolué est une PME de moins de 10 employés qui produit et vend ses articles à l'unité ou en kits pour des professionnels ou des particuliers. La force de cette entreprise est sa capacité à produire en moins de deux semaines un article de grande qualité issu d'un catalogue composé d'un grand nombre de références, mais aussi à produire de nouveaux articles selon la demande.

    Cette flexibilité dans les références proposées est la grande force de l'entreprise, mais le stockage d'un tel nombre de références devient rapidement un enfer, surtout lorsque les contraintes physiques de stockage ne peuvent pas être changées.

    "Quelles références stocker ? Est-ce que j'ai du stock ? Qu'est-ce qu'il faut lancer en production ?"

    Tout un ensemble de questions auxquelles l'entreprise, la tête dans le guidon, n'arrivait à y répondre qu'au jour le jour, selon l'expérience de quelques employés.

    Tous les ordres de production qui en résultaient étaient des fiches de modèle qui s'entassaient en production et un numéro de quantité à produire. Mais au fil de la production, cela perdait de son sens en fonction des stocks qui étaient déjà présents, des rebuts en production et des stocks tampons que l'entreprise voulait maintenir. Bref, l'entreprise fonctionnait à l'aveugle, dans une tempête de références, de quantités, de commandes, etc.

    Face à ce chaos opérationnel, l'objectif était clair : remplacer les outils existants, trop fragmentés ou inexistants, par un Progiciel de Gestion Intégré (ERP) unique, adapté et entièrement personnalisé pour les processus spécifiques de cette PME.

    Un visuel symbolisant le "Chaos" (une étagère désordonnée, des papiers empilés, des ordres de production qui se chevauchent) opposé à l'"Ordre" (un écran d'ordinateur clair affichant des données structurées). Cela accroche immédiatement le lecteur sur la transformation.

    Dans cet article, je vais détailler les six mois intenses de ce projet. Nous allons explorer comment les trois premiers mois ont été consacrés à une analyse terrain rigoureuse pour comprendre les besoins réels, et comment les trois mois suivants ont permis de concevoir, développer et déployer cet ERP sur mesure qui a transformé leur manière de travailler.

    Partie 1 : La Phase de Diagnostic et d'Immersion (Mois 1 à 3)

    L'objectif de cette partie est de valider la compréhension métier et de justifier les spécifications fonctionnelles avant tout développement technique.

    A- Le terrain : Plongée dans les Opérations

    Le Mythe et la réalité

    Comme c'est souvent le cas dans les PME qui croissent rapidement, l'entreprise est venue me voir avec ses propres observations et conclusions sur les problèmes à résoudre. L'équipe, la tête dans le guidon, pointait du doigt ce qu'elle ressentait : un manque de visibilité, des erreurs de stock, ou des retards dans la production. Or, ces observations, bien que sincères, venaient avec certains biais et ne pointaient pas forcément la ou les causes racines du problème.

    Il y a un monde entre un sentiment opérationnel et la mesure factuelle : c'est l'écart que nous devions combler. Ma première mission durant ces trois mois a été d’écarter ces biais pour déterrer la véritable cause racine. Par exemple, les employés pensaient "Nous n'avons jamais le bon stock". Mais l'analyse a révélé que le stock était bien là ; c'était le processus de mise à jour et de consommation qui était défaillant, transformant un problème de gestion en un problème perçu de logistique.

    Cette première phase d’analyse n'était pas un luxe, c'était une nécessité. Elle a permis de transformer des hypothèses subjectives en un diagnostic technique précis qui allait garantir que le futur ERP résolve les vrais problèmes, et non pas seulement les symptômes.

    Une illustration de l'iceberg où seule la pointe (les symptômes : "erreurs de stock") est visible, et l'immense base immergée (la cause racine : "processus de mise à jour défaillant") est montrée. Illustre la transition du sentiment à la mesure factuelle.

    Méthode de travail

    Pour passer efficacement du sentiment à la mesure, j'ai structuré ces trois mois autour d'une approche hybride alliant immersion et quantification des processus :

    • Le Qualitatif (Écoute et Immersion) : J'ai mené des entretiens individuels pour saisir les frustrations et comprendre les workarounds — les méthodes de contournement non officielles utilisées par les employés. J'ai également procédé à l'Observation des flux de travail (Job Shadowing), passant du temps directement à l'atelier, aux bureaux et à la logistique, et non pas seulement devant un écran pour garantir que l'ERP serait une solution de terrain.

    • Le Quantitatif (Mesure, VSM et Priorisation) : Lors de cette observation en production, j'ai utilisé des outils de diagnostic avancés, notamment la Cartographie de la Chaîne de Valeur (VSM - Value Stream Mapping). L'objectif était de décomposer les temps entre ce qui était à valeur ajoutée et ce qui n'en était pas (attentes, transports inutiles, sur-stocks tampons, etc.) pour identifier les goulots d'étranglement et le lead time réel. Toutes ces mesures brutes ont été organisées dans un immense fichier Excel. L'outil clé fut l'application de la courbe de Pareto, ce qui m'a permis d'isoler les 20 % des processus qui étaient responsables de 80 % du chaos et de définir les priorités d'automatisation de l'ERP.

    • Le Consensuel : Enfin, des ateliers de groupe ont permis de valider ces mesures factuelles et les conclusions de l'analyse, garantissant que les spécifications futures bénéficieraient du consensus de l'équipe.

    B- Identifier les Points de Friction Clés

    Problèmes Spécifiques Découverts

    L'analyse quantitative et qualitative a révélé deux paradoxes majeurs, caractéristiques d'une production rapide mais mal gérée :

    1. Le Paradoxe du Stock : L'entreprise souffrait d'un problème de stock inversé. Il y avait un surstock coûteux de matières premières et de produits finis, qui immobilisait du capital. Simultanément, il y avait une pénurie chronique de "pièces brutes" ou de semi-finis, pourtant essentiels pour répondre rapidement à la demande. Ce déséquilibre était directement lié à l'absence de déclinaison des références en fonction de leurs bases communes et à une mauvaise priorisation.

    2. Le Goulot d'Étranglement : La VSM a clairement identifié le goulot d'étranglement entre les machines de production pure et la post-production (finitions rapides). Les machines de production, coûteuses, ne pouvaient pas tourner en continu faute d'espace ou de clarté sur la suite. Pour résoudre cela sans changer l'infrastructure physique, nous avons décidé de mettre en place un stock tampon dimensionné et géré de manière plus efficace entre ces deux secteurs.

    Justification de l'ERP : Du Stockage Physique au Suivi Intelligent

    Toutes ces conclusions ont convergé vers une seule nécessité : un outil informatique centralisé (l'ERP). Le problème n'était pas l'absence de stock, mais l'absence de stockage intelligent et de visualisation de celui-ci.

    Le futur ERP devait répondre à des fonctionnalités fondamentales basées sur les principes du Lean Management :

    • Gestion des États des Articles : Le système devait intégrer une gestion des états des articles, y compris ceux en cours de production. L'objectif était de ne jamais perdre de vue une pièce, de son lancement à sa livraison.

    • Priorisation Dynamique : L'ERP devait automatiser la priorisation des lancements de production en fonction des commandes réelles et de l'état des stocks, mettant fin aux lancements "non prioritaires" qui causaient des retards de livraison.

    • Analyse des Rebuts : Pour permettre une amélioration continue, le système devait permettre de suivre les causes des rebuts en production. Cela ouvre la voie à une analyse des causes racines et à des actions correctives, s'inscrivant parfaitement dans une démarche de Lean Management à long terme.

    C'est sur la base de ces conclusions et des fonctionnalités vitales identifiées que nous avons pu rédiger un cahier des charges précis, mettant fin aux généralités pour se concentrer sur la création de valeur.

    C- Des Livrables à Double Impact : Organisation et Numérisation

    La conclusion de cette phase d'analyse de trois mois s'est traduite par deux catégories de livrables, l'une immédiate et l'autre préparant la suite du projet :

    1. Le Diagnostic 4.0 et les Recommandations Opérationnelles (Court Terme) :

      • Les Données Brutes : Nous avons produit un immense fichier Excel servant de "donnée source" pour tous les outils de diagnostic (VSM, Pareto). Ce fichier contenait toutes les mesures de temps, d'état et de flux observées sur le terrain.

      • Les Conclusions à Coût Zéro : Le diagnostic a permis de distinguer les problèmes logiciels des problèmes d'organisation pure. Par exemple, la solution au goulot d'étranglement a été en partie résolue par une réorganisation du stockage à coût quasi nul, grâce à une meilleure segmentation des pièces brutes.

      • La Vision Stratégique : Les conclusions ont montré que la seule manière de gérer durablement la complexité des références et d'assurer une production fluide était de donner une vision en temps réel sur la production et les stocks via un outil informatique.

    2. Le Cahier des Charges de l'ERP et les Prototypes (Mise en Œuvre) :

      • Cahier des Charges Détaillé : Nous avons formalisé un document précis décrivant les fonctionnalités essentielles de l'ERP. Ce n'était pas un document générique, mais un plan d'attaque ciblé sur les besoins vitaux identifiés : gestion des stocks bruts/finis, suivi d'état, priorisation dynamique et traçabilité des rebuts.

      • Wireframes et Prototypes : Des maquettes d'écran ont été créées pour les modules clés afin de valider l'ergonomie et l'expérience utilisateur (UX) avec les équipes terrain. C'était la dernière étape de la co-construction avant de passer aux "choses sérieuses" : le développement.

    Ces livrables ont marqué la fin de la phase d’analyse et le début de l'exécution, transformant une série de frustrations en un plan d'action technique et organisationnel concret.

    Partie 2 : La Phase de Conception et de Réalisation (Mois 4 à 6)

    A- Choix technologiques

    Le Pragmatisme Avant l'Esthétisme : Pourquoi VB ?

    Avec seulement trois mois alloués à la conception, au développement, au test et au déploiement d'un ERP complet, les contraintes de temps, de budget et d'infrastructure ont été les seuls éléments qui ont dicté la stack technique. L'objectif n'était pas de construire une application web moderne, mais une solution fonctionnelle, robuste et livrable dans les délais.

    Le choix s'est donc basé sur des éléments très pragmatiques :

    • Délai Extrêmement Court : Trois mois pour un ERP est une période extrêmement courte. La priorité absolue était la rapidité de prototypage et de développement, en sacrifiant tout ce qui n'était pas essentiel à la fonction métier (comme une interface utilisateur sophistiquée).

    • Infrastructure Existante : L'entreprise ne disposait d'aucune infrastructure Cloud. L'application devait être hébergée localement, avec la base de données résidant sur le serveur de la PME. Pas de coût mensuel supplémentaire.

    • Focus Fonctionnel (Proof of Concept Rapide) : Il n'y avait pas de temps à perdre dans la construction d'un thème graphique moderne, la gestion de l'adaptabilité mobile ou l'optimisation des performances front-end. L'application devait simplement faire le travail : afficher les données, gérer les stocks, calculer les priorités.

    Par conséquent, je me suis orienté vers un environnement qui maximise la productivité en développement : Visual Basic (VB) (notamment VB.NET ou un environnement similaire de développement rapide d'applications de bureau).

    Ce choix, qui peut paraître désuet, était en réalité le plus judicieux pour cette mission :

    • Rapidité de Création d'Écrans : VB permet de créer rapidement des interfaces utilisateur (formulaires, tableaux de données) par glisser-déposer. Cela a permis de transposer les wireframes de la Phase 1 en outils fonctionnels en quelques jours, facilitant les tests utilisateurs précoces.

    • Simplicité de Connexion à la Base de Données : L'intégration avec la base de données locale (PostgreSql) est native et simple.

    • Performance Locale : En tant qu'application de bureau, elle offre une performance rapide sur le réseau local de l'entreprise sans dépendre de la bande passante Internet.

    • Robustesse : Une application de bureau locale est plus facile à sécuriser et à maintenir dans un environnement sans équipe IT dédiée, ce qui était le cas de cette PME.

    En somme, l'architecture choisie est celle d'une application "gros client" (fat client), mais c'est précisément ce qui a permis de respecter le délai impératif de 3 mois et de garantir que la solution soit opérationnelle sur l'infrastructure existante.

    B- Le défi du Développement Sur-Mesure

    L'Agilité au Service de l'Urgence

    Malgré le délai serré de trois mois pour le développement, il était crucial d'adopter une approche structurée pour garantir la livraison et l'adhésion. Le développement a été organisé autour de sprints itératifs courts (généralement d'une à deux semaines), permettant de livrer des fonctionnalités testables très rapidement.

    Cette organisation agile a permis :

    1. Le Développement Progressif des Modules : Plutôt que de tout construire en parallèle, nous avons privilégié un développement séquentiel, en commençant par les modules de bases et la structuration de la base de données. Au total, le code se composait de 6 modules : les articles & kits (composition / stockage), les commandes, l'ordonnancement, la production, la post-production et l'expédition.

    2. L'Intégration du Feedback Continu : À la fin de chaque sprint, nous tenions une mini-démonstration avec les utilisateurs clés. Cela garantissait que l'ERP évoluait en phase avec les besoins réels du terrain, évitant l'effet tunnel et les mauvaises surprises au moment du déploiement. L'une des remarques qui avait été remontée portait sur la taille des éléments de l'écran de post-production car tout était trop "petit" vu l'emplacement de l'écran sur le poste de travail.

    Chaque module avait vraiment son contexte d'utilisation bien précis et par conséquent ses utilisateurs clefs spécifiques à intégrer dans le processus de création de l'outil à chaque sprint.

    Focus sur les Modules Clés

    Deux modules en particulier ont été le cœur de ce développement sur-mesure et ont eu un impact maximal sur la PME :

    • 1. Le Module de Priorisation des Lancements (Le "Chef d'Orchestre") : C'était la clé de voûte pour résoudre le problème du goulot d'étranglement. Ce module prenait en compte l'état des commandes client, le stock disponible de pièces brutes, et les temps de production mesurés (issus de la VSM). Il produisait une liste de production optimisée, indiquant clairement à l'atelier non seulement quoi produire, mais dans quel ordre précis, garantissant que les machines tournent sur les produits les plus urgents et les plus créateurs de valeur.

    • 2. La Gestion des États et des Stocks Tampons (La "Vision en Temps Réel") : Ce module a permis de matérialiser la vision en temps réel des pièces, même en cours de transformation. Grâce à une interface simple, chaque opérateur pouvait scanner ou mettre à jour l'état d'une pièce ("Brut", "En Post-Production", "Rebut", "Stock Tampon X"). Cela a rendu le stock tampon visible et intelligent, assurant que la post-production sache exactement ce qui arrivait et quand, ce qui a stabilisé le flux entre les deux secteurs.

    Ces fonctionnalités, développées sur mesure, ont transformé l'ERP d'un simple outil de saisie de données en un véritable outil de pilotage opérationnel.

    La mise en production

    La mise en production, ou Go-Live, est l'aboutissement de ces trois mois de développement. Elle nécessitait une exécution méthodique pour assurer une transition fluide :

    Pour garantir la fiabilité immédiate du nouvel ERP, nous avons mené la migration des données à partir des modèles Excel précis construits ensemble lors de la phase de diagnostic. Crucialement, juste avant le lancement, un inventaire physique complet a été réalisé. Ces données d'inventaire ont été importées comme stock initial de référence, servant de point de départ unique et vérifié pour l'application.

    Après une formation ciblée sur les modules prioritaires, l'application a été lancée. L'adoption a été progressive, les équipes se familiarisant avec le nouveau mode de travail — basé sur la donnée en temps réel plutôt que sur l'expérience.

    Une fois l'application en service, une période de support intensif a été essentielle. Les utilisateurs finaux ont révélé de petits bugs et, surtout, des incohérences dans les données restantes qui n'avaient pas été entièrement purgées ou normalisées. Ces erreurs étaient un héritage de l'ancien système. En mode réactif, nous avons pu corriger ces anomalies rapidement, assurant ainsi une confiance croissante dans l'outil et stabilisant la base de données pour une utilisation durable. Cette phase a prouvé la résilience du système et l'engagement à l'accompagner après le déploiement.

    Conclusion et Perspectives

    A- Bilan et Résultats (Impact)

    Le déploiement de l'ERP sur mesure n'a pas été une simple mise à jour technique ; il a catalysé une transformation opérationnelle complète au sein de la PME. Les impacts mesurables sont regroupés autour de trois axes fondamentaux :

    • Productivité Optimisée : Le Module de Priorisation a permis d'éliminer les temps morts et les lancements "non prioritaires". En maximisant le Taux d'Utilisation des Capacités (TUC) du goulot d'étranglement, la PME a pu observer une augmentation significative de sa capacité de production sans investissement matériel additionnel. La gestion intelligente des stocks tampons a permis de fluidifier l'interfaçage entre les machines pures et la post-production, créant un flux tiré plus stable.

    • Qualité et Amélioration Continue : Grâce à l'intégration du suivi des rebuts, l'entreprise a acquis un nouvel outil de Maîtrise de la Qualité. Le système permet désormais une traçabilité systématique des défauts, ouvrant la voie à une Analyse des Causes Racines (RCA) et à des actions correctives ciblées, formalisant ainsi une démarche d'amélioration continue basée sur les principes du Lean Management.

    • Fiabilité Accrue : L'impact le plus spectaculaire a été la réduction drastique des incertitudes. La visibilité en temps réel sur l'état de chaque article en production, combinée à la priorisation des lancements, a permis de réduire les retards de livraison de près de 80 %. Cette amélioration du Respect des Délais de Livraison (OTD - On-Time Delivery) a directement renforcé la crédibilité et la fiabilité de l'entreprise auprès de ses clients professionnels.

    Livraisons retardées

    B- Les Leçons Apprises

    Ce projet de six mois, couvrant l'analyse, la conception, le développement, la migration et le support, constitue l'expérience la plus riche de ma carrière à ce jour. La complexité inhérente à la transformation numérique d'une structure existante a forgé des compétences clés.

    J'ai pu mesurer l'importance capitale d'une écoute active et de la gestion des parties prenantes. Un ERP, même le plus performant, est voué à l'échec sans l'adhésion des utilisateurs finaux. Le succès repose sur une démarche itérative de co-construction et de validation continue, transformant la résistance potentielle en appropriation.

    Ce projet a confirmé que la phase de diagnostic (Mois 1 à 3) est le véritable déterminant de la réussite. Les outils d'analyse structurée, tels que la VSM et Pareto, sont indispensables pour passer du symptôme à la cause racine et pour définir des spécifications qui créent une valeur réelle et mesurable.

    J'exprime ma profonde gratitude envers l'entreprise pour m'avoir accordé sa confiance sur un projet d'une telle envergure. Cette confiance a été gagnée et entretenue par une approche structurée et transparente, livrant des jalons tangibles à intervalles réguliers. C'est cette dynamique qui permet d'atteindre l'accomplissement professionnel de livrer une solution complète ayant un impact économique direct et positif. Je suis impatient de réitérer des missions de cette magnitude dans le futur.

    Et maintenant, la suite ? Interagissons !

    Ce projet représente bien plus qu'une ligne sur mon CV : c'est un cas d'étude concret de la manière dont une PME peut se moderniser et gagner en performance.

    1. Vos Questions, Mes Réponses : Avez-vous rencontré des problématiques similaires ? Souhaitez-vous explorer un point technique précis (comme la modélisation de la base de données ou le détail du calcul de la priorité) ? Laissez un commentaire ou contactez-moi directement, je serai ravi d'approfondir cet échange.

    2. Découvrez d'Autres Projets : Si l'approche Lean et le développement sur mesure vous intéressent, je vous invite à consulter mes autres articles où je détaille d'autres réalisations dans l'optimisation des processus et le développement d'outils digitaux.

    3. Parlons de votre Prochaine Transformation : Votre entreprise fait face à un "chaos opérationnel" similaire ? Les solutions sur étagère ne répondent pas à vos processus uniques ? N'hésitez pas à me contacter pour discuter de vos propres besoins en ERP, en optimisation de flux (VSM) ou en développement d'outils sur mesure. L'étape la plus difficile est toujours le premier diagnostic ; je peux vous aider à le structurer.


    # Application Vb.net Diagnostique 4.0 ERP Lean Management Projet
    Comment j'ai construit un ERP de A à Z pour transformer une PME ?
    Baquedano Nathan Conseils, Nathan Baquedano 26 novembre 2025
    Partager cet article
    Étiquettes
    Application Vb.net Diagnostique 4.0 ERP Lean Management Projet
    Archive
    Liens utiles
    • Accueil
    • Plans tarifaires
    • À propos de moi
    • Contactez-moi
    À propos de moi

    Je me nomme Nathan BAQUEDANO, je suis passionné par l'innovation et je m'engage à améliorer la vie de chacun grâce à des solutions créatives. Je conçois des produits sur mesure pour répondre à vos besoins commerciaux.

    Mes solutions sont idéales pour les petites et moyennes entreprises cherchant à maximiser leur efficacité.

    Rejoignez-nous
    • Contactez-moi
    • [email protected]
    • +33 6 41 80 12 72​
    Suivez-nous
    Copyright © Baquedano Nathan Conseils
    Généré par Odoo - Créer un site web gratuit