Le progiciel de gestion intégré (ERP)
- Code
- TM 29
- Public
- Rayon disciplinaire, tous publics
- Cours
- 10 pages, PDF
- Diaporama
- 25 diapositives, thèmes sombre et clair, PowerPoint modifiable et PDF
- Synthèse
- 2 pages, PDF
- Podcast
- Fichier audio
- Vidéo
- Fichier vidéo MP4
- Infographie
- L'essentiel de la fiche sur une image
- Avec l'achat
- Téléchargement dans votre espace client
Une erreur de saisie touche une pièce et se voit ; une erreur de paramétrage touche toutes les pièces d'une catégorie, se répète sans alerte et ne se détecte qu'au contrôle. Tout le déplacement opéré par le progiciel de gestion intégré tient dans cette phrase : le gestionnaire ne produit plus l'écriture, il configure la règle qui la produira des milliers de fois.
Voir ce que traite le cours
Cours
10 pages rédigées, en PDF.

Diaporama
25 diapositives en PowerPoint modifiable, thème sombre pour projeter et thème clair pour imprimer.

Synthèse
2 pages pour réviser l'essentiel.
Podcast
La notion expliquée à l'oral, à écouter hors de l'écran.
Vidéo
Une présentation animée de la notion, en MP4.
Infographie
L'essentiel de la fiche sur une image.
Ce que traite le cours
9 sections, 10 pages
- ID'où vient le progiciel intégré : trois réponses successives à un même problème
- IIUne base unique, une saisie unique : ce que l'intégration change réellement
- IIILe paramétrage : configurer la règle plutôt que produire l'écriture
- IVErreur de saisie et erreur de paramétrage : deux régimes de risque
- VHabilitations, séparation des tâches et piste d'audit
- VIConduire le projet : phases, stratégie de bascule, reprise des données
- VIIPourquoi les projets échouent : six cas documentés
- VIIIChoisir sa solution : adéquation, coût complet, dépendance consentie
- IXLe progiciel comme socle de pilotage et comme fait organisationnel
Notions, outils et auteurs
Chaque repère mène aux autres fiches qui le traitent.
Notions
Modèles et outils
- MRP (Material Requirements Planning)
- MRP II (Manufacturing Resource Planning)
- ERP / progiciel de gestion intégré
- table de comptabilisation à deux entrées et deux sorties
- rapprochement à trois voies
- grille des quatre fonctions incompatibles
- séquence de projet de Markus et Tanis
- courbe de baisse de performance de Ross et Vitale
Présentation de la notion
Une base unique, une saisie unique
La fiche part de la propriété dont tout découle — une seule base de données, une donnée saisie une seule fois — et en tire les trois effets : disparition des erreurs de transcription, information disponible en temps réel, traçabilité continue de l'écriture jusqu'au devis. Le revers y est exposé : une donnée fausse se propage aussi vite qu'une donnée juste. Un tableau détaille les sept modules — commercial, achats, stocks, production, paie, immobilisations, trésorerie — et ce que chacun déclenche ailleurs. La comptabilité y apparaît pour ce qu'elle est devenue : un point d'arrivée, jamais un point de saisie.
Le paramétrage et le risque qu'il porte
La fiche traite ensuite la table de comptabilisation — croiser une famille d'articles et une catégorie de tiers pour en déduire le compte mouvementé et le traitement fiscal — puis les trois couches du paramétrage : configuration standard, personnalisation dans les espaces d'extension prévus, développement spécifique dont le coût se paie à chaque montée de version. Un tableau oppose ligne à ligne l'erreur unitaire et l'erreur systématique : objet atteint, visibilité, propagation, détection, correction en deux temps — la règle d'abord, le stock d'écritures déjà produites ensuite.
Maîtrise, projet, choix de la solution
- Les habilitations : moindre privilège, rapprochement à trois voies, et les quatre fonctions à ne jamais cumuler — autoriser, exécuter, conserver, enregistrer.
- Cinq phases de projet dans la filiation de Markus et Tanis (2000), quatre stratégies de bascule, reprise des données et creux de performance qui suit la mise en service (Ross et Vitale, 2000).
- Six échecs documentés — FoxMeyer, Hershey, Nike, Waste Management, Lidl, Revlon — dont aucun n'est d'ordre proprement technique, et un cas travaillé sur Lidl.
- La sélection : solution installée, en nuage ou libre ; coût complet sur cinq à sept ans, réversibilité, dépendance à l'éditeur.
À qui elle s'adresse
Aux formateurs et étudiants en gestion, comptabilité et management des organisations. La filiation du MRP d'Orlicky (1975) à l'ERP forgé chez Gartner en 1990 y est retracée, et le progiciel traité comme un fait organisationnel autant que comme un outil. Repères réglementaires arrêtés au 31 août 2026, glossaire et sources vérifiables.
Objectifs de la fiche
- Expliquer ce que l'unicité de la base et de la saisie change réellement — temps réel, traçabilité continue, mais propagation immédiate d'une donnée fausse
- Lire une table de comptabilisation et distinguer les trois couches du paramétrage : configuration standard, personnalisation, développement spécifique
- Différencier une erreur de saisie d'une erreur de paramétrage, puis conduire la correction dans le bon ordre — la règle d'abord, le stock d'écritures ensuite
- Construire un plan d'habilitations fondé sur le moindre privilège, le rapprochement à trois voies et la séparation des fonctions d'autorisation, d'exécution, de conservation et d'enregistrement
- Structurer un projet de progiciel intégré en cinq phases, arbitrer entre les stratégies de bascule et sécuriser la reprise des données
- Comparer une solution installée, en nuage ou libre sur le coût complet, la maîtrise des données et la réversibilité avant la signature
Questions fréquentes
Quelle différence entre une erreur de saisie et une erreur de paramétrage ?
L'erreur de saisie touche une pièce, parfois quelques-unes, et se voit le plus souvent : montant aberrant, rapprochement qui échoue, réclamation d'un tiers. L'erreur de paramétrage touche toutes les pièces d'une catégorie, sans exception, et reste invisible puisque la règle s'applique uniformément sans déclencher aucun signal. Elle se détecte par revue analytique, sondage ou audit de configuration, et se corrige en deux temps obligatoires : corriger la règle, puis reprendre le stock d'écritures déjà produites.
Faut-il adapter le progiciel à ses processus, ou l'inverse ?
La question utile n'est jamais « le progiciel sait-il faire comme nous ? » mais « notre manière de faire porte-t-elle un avantage que nos clients paient ? ». Si la réponse est non, c'est le processus qui s'aligne sur le standard. Un développement spécifique doit être testé, corrigé et parfois réécrit à chaque montée de version : son coût n'est pas celui de sa création, mais celui de sa création multipliée par le nombre de versions à venir. Le cas Lidl, arrêté en 2018 après sept années, illustre le prix d'un spécifique de principe.
Pourquoi les projets de progiciel intégré échouent-ils ?
La fiche examine six échecs publics et documentés — FoxMeyer, Hershey, Nike, Waste Management, Lidl, Revlon — et la technique n'y est jamais la cause dominante. Reviennent d'un cas à l'autre la fenêtre de bascule choisie sur le calendrier du projet plutôt que sur celui de l'activité, le volume de développement spécifique, la qualité des données reprises et le sous-dimensionnement de la formation. Un tel projet est une refonte des processus de travail dont l'outil n'est que le support.