Les étapes du développement d'un ERP sur mesure

Un ERP sur mesure, ce n'est pas un logiciel de plus. C'est le système nerveux de vos opérations : la production, les achats, le temps des employés, la facturation, les stocks. Quand il fonctionne, personne n'en parle. Quand il échoue, tout l'atelier s'arrête.

Les six étapes d'un projet ERP sur mesure : comprendre les opérations, décider ce qu'on ne construit pas, poser l'architecture, développer par tranches utilisables, tester, puis déployer et former. Voici chacune d'elles — et surtout, ce qui la fait dérailler. C'est écrit à partir de systèmes que nous avons réellement livrés, pas d'un modèle générique.

1. Comprendre les opérations avant de parler de logiciel

La première étape n'est pas technique. Il s'agit de comprendre comment le travail se fait aujourd'hui — y compris les contournements que personne n'assume.

Dans presque tous les ateliers où nous sommes intervenus, il existe un fichier Excel officieux que quelqu'un maintient à la main depuis des années. Ce fichier contient souvent les règles de fonctionnement les plus importantes de l'entreprise. Le rater à l'analyse, c'est livrer un ERP que personne n'utilisera.

Ce qu'il faut cartographier :

• Le parcours réel d'une commande, de la soumission à la facturation
• Qui saisit quoi, quand, et à partir de quelle source
• Les points où l'information est ressaisie une deuxième fois
• Ce qui se passe quand ça déraille : rupture de stock, machine en panne, commande urgente

Ce qui fait échouer cette étape : interroger uniquement la direction. Les personnes qui connaissent les vrais processus sont sur le plancher, et ce sont elles qui utiliseront le système tous les jours.

2. Décider ce qu'on ne construit pas

Un ERP peut tout faire. C'est précisément le problème.

La deuxième étape consiste à tracer une frontière : quelles fonctions vont dans l'ERP, lesquelles restent dans les outils existants, et lesquelles disparaissent parce qu'elles ne servaient à rien.

Cette décision détermine le budget bien plus que le choix des technologies. Un ERP qui remplace six fichiers Excel critiques coûte une fraction d'un ERP qui prétend remplacer aussi la comptabilité, la paie et le CRM.

Souvent, la meilleure réponse n'est pas de tout absorber mais de connecter. Pour un manufacturier, nous avons bâti un connecteur qui transfère automatiquement les cartes de temps de l'ERP vers le logiciel comptable Avantage. La comptabilité est restée où elle était ; seule la double saisie a disparu.

3. L'architecture et les fondations

Avant d'écrire une seule fonctionnalité, il faut poser les bases : structure du projet, choix des technologies, modèle de données, gestion des accès, environnements de développement, de préproduction et de production, et déploiement automatisé.

Sur un ERP, le modèle de données mérite une attention particulière. C'est la décision la plus coûteuse à corriger plus tard : changer la façon dont une commande est reliée à ses pièces, ses bons de travail et ses achats, six mois après le démarrage, revient souvent à réécrire la moitié du système.

Deux questions à trancher tôt :

• Quelle est la durée de vie visée ? Un ERP se garde dix à quinze ans. Nous avons modernisé pour un atelier d'usinage un système DOS qui tournait encore, et qui avait largement dépassé cette durée.
• Qui hérite du code ? Un ERP sur mesure vous appartient. Assurez-vous que son architecture soit lisible par une autre équipe que celle qui l'a bâti.

4. Le développement, par tranches utilisables

L'erreur classique consiste à développer l'ERP complet pendant douze mois, puis à le livrer d'un coup. Personne ne l'adopte, et les écarts avec la réalité du terrain n'apparaissent qu'à la toute fin, quand ils coûtent le plus cher à corriger.

La bonne approche livre des tranches utilisables. Un module de bons de travail qui fonctionne vraiment vaut mieux que quinze modules à moitié faits. Chaque tranche mise en production révèle des choses que l'analyse n'avait pas vues — et il vaut mieux les découvrir au troisième mois qu'au douzième.

C'est aussi ce qui rend l'adoption possible : les équipes apprennent le système progressivement, au lieu de tout réapprendre en une semaine.

5. Les tests, et ce qu'ils doivent couvrir

Sur un ERP, les tests ne servent pas seulement à vérifier que les boutons fonctionnent. Ils servent à protéger les calculs.

Ce qu'il faut couvrir en priorité :

• Les calculs de coûts, de temps et de quantités — là où une erreur se propage silencieusement dans toute la chaîne
• Les intégrations avec les systèmes externes, qui cassent quand l'autre logiciel se met à jour
• Les cas limites : commande annulée en cours de production, retour de matériel, employé qui poinçonne deux fois

Un ERP mal testé ne plante pas : il donne des chiffres légèrement faux pendant des mois, et personne ne s'en aperçoit avant l'inventaire annuel.

6. Le déploiement, la formation et l'après

Le déploiement d'un ERP est un changement organisationnel avant d'être un événement technique. Les points qui comptent :

• Basculer par étapes, pas d'un coup. La production ne peut pas s'arrêter pendant qu'on migre.
• Former sur le terrain, avec les vraies données de l'entreprise plutôt qu'un jeu de démonstration.
• Prévoir une période de double saisie sur les processus critiques, le temps de valider que les chiffres concordent.
• Identifier les personnes-relais dans chaque équipe : elles feront plus pour l'adoption que n'importe quelle documentation.

Et surtout : un ERP n'est jamais terminé. Il évolue avec l'entreprise. Prévoyez un budget de maintenance annuel — correctifs, mises à jour de sécurité, adaptation aux changements de vos partenaires, nouvelles fonctionnalités.

Ce que l'IA change réellement sur un projet ERP

La production de code s'est nettement accélérée. Ce qui n'a pas accéléré : comprendre vos opérations, choisir le bon modèle de données, sécuriser les accès, décider ce qu'on ne construit pas. Ces décisions restent le travail de développeurs chevronnés, et ce sont elles qui déterminent si l'ERP tiendra dix ans.

En revanche, l'IA a ouvert une possibilité qui n'existait pas : l'utiliser dans l'ERP. Pour un atelier d'usinage, nous avons bâti une planification de production assistée par l'IA, qui priorise les travaux en tenant compte des dates de livraison, de la disponibilité des machines, des employés et des imprévus. C'est le genre de fonction qui était hors budget il y a trois ans.

Faut-il un ERP sur mesure ou un progiciel du marché ?

La question mérite d'être posée avant de dépenser un dollar.

Un progiciel du marché convient quand vos processus ressemblent à ceux de votre secteur, que vous êtes prêt à adapter vos façons de faire au logiciel, et que les modules standards couvrent l'essentiel.

Le sur mesure se justifie quand votre façon de travailler est justement votre avantage concurrentiel, quand aucun progiciel ne couvre votre réalité sans contorsions coûteuses, ou quand vous accumulez déjà les fichiers Excel parallèles parce que le système officiel ne suit pas.

Le signal le plus clair : si vos équipes maintiennent des fichiers en marge du logiciel que vous payez, c'est que le logiciel ne fait pas la job.

Nous traitons cet arbitrage en détail, au-delà du cas des ERP, dans notre article développer ou acheter un logiciel.

Combien de temps, combien ça coûte

Un ERP sur mesure pour une PME se compte en mois, pas en semaines — généralement de quatre à douze mois selon la portée, avec des mises en production progressives dès les premiers mois.

Côté budget, les fourchettes suivent celles de tout projet logiciel sur mesure, avec une nuance : la part d'analyse y est plus élevée qu'ailleurs, parce que c'est elle qui détermine tout le reste. Nous détaillons les fourchettes par taille de projet dans notre article sur le coût d'un logiciel sur mesure au Québec.

Notre page ERP et systèmes de gestion sur mesure détaille les modules que nous livrons et les systèmes déjà en service chez des clients.

Si vous en êtes à évaluer un projet ERP, la conversation la plus utile ne porte pas sur les technologies. Elle porte sur ce qui coince aujourd'hui dans vos opérations, et sur ce que ça vous coûte de le laisser coincer.