Pourquoi ce choix se fait souvent mal
La question est rarement posée à froid : elle arrive avec un éditeur qui présente son produit, ou une équipe qui veut son outil. Chaque camp a de bons arguments, et le débat tourne vite à la préférence.
- On compare des prix qui ne se comparent pas : des licences d’un côté, un devis de développement de l’autre, sans l’intégration, la maintenance, les évolutions ni la sortie.
- On confond standard et habitude : beaucoup de « spécificités » sont des façons de faire qu’un progiciel couvre très bien, à condition d’accepter d’adapter le processus.
- On sous-estime ce qui est vraiment propre à l’entreprise : à l’inverse, un processus qui fait la différence commerciale, déformé pour entrer dans un progiciel, perd ce qui le rendait utile.
- On oublie ce qui existe déjà : les logiciels en place, leurs interfaces, les compétences internes : un choix qui ignore l’écosystème le paie à l’intégration.
Choisir, c’est trier processus par processus ce qui est standard et ce qui est différenciant, puis chiffrer chaque option sur toute sa durée de vie.
La démarche de choix en six étapes
- CartographierProposé, puis validé
- Standard ou différenciantDécidé par une personne
- Fixer la grilleProposé, puis validé
- Chiffrer le coût completProposé, puis validé
- Tester les vrais casProposé, puis validé
- DéciderDécidé par une personne
Le détail de chaque étape : ouvrez-la.
Cartographier les processus concernés
- Aujourd’hui
- Besoin exprimé en liste de fonctions, souvent reprise d’un cahier des charges type.
- Automatisé
- Carte des processus réels : qui fait quoi, avec quel outil, quelles données entrent et sortent, quels volumes.
- Reste humain
- Faire valider la carte par les équipes qui font le geste chaque jour.
Séparer le standard du différenciant
- Aujourd’hui
- Chaque service juge son processus unique.
- Automatisé
- Chaque processus classé : standard (se fait partout de la même façon), réglementé, ou différenciant (fait la différence auprès des clients).
- Reste humain
- Arbitrer en direction : accepter d’adapter un processus standard, protéger un processus différenciant.
Fixer la grille de critères
- Aujourd’hui
- Critères implicites, différents pour chaque participant.
- Automatisé
- Grille commune : volumétrie, réglementation, coût complet, réversibilité et propriété du code, compétences internes, délai, écosystème existant.
- Reste humain
- Pondérer les critères avant de voir la moindre offre.
Chiffrer le coût complet de chaque option
- Aujourd’hui
- Prix d’achat ou de licence comparé à un devis de développement.
- Automatisé
- Coût de possession sur la durée : licences ou développement, intégration, reprise de données, maintenance, évolutions, formation, sortie.
- Reste humain
- Vérifier les hypothèses avec la finance et la DSI.
Éprouver les options sur les vrais cas
- Aujourd’hui
- Démonstration préparée par l’éditeur ou le prestataire, sur ses propres exemples.
- Automatisé
- Démonstration ou prototype sur les cas réels de l’entreprise, y compris les exceptions, avec ses propres données.
- Reste humain
- Les équipes métier jugent sur ce qu’elles voient faire, pas sur ce qu’on leur promet.
Décider et écrire pourquoi
- Aujourd’hui
- Décision prise en réunion, motifs non écrits.
- Automatisé
- Rien : la grille et le chiffrage éclairent la décision, ils ne la prennent pas.
- Reste humain
- La direction décide, processus par processus, et consigne les motifs pour pouvoir les revoir.
Les prérequis
- Un sponsor à la direction qui arbitre entre les services, en particulier quand un processus standard doit être adapté.
- La DSI et la finance associées dès le départ l’une pour l’écosystème et les compétences, l’autre pour le coût complet.
- Les volumes et les cas réels commandes, articles, factures, utilisateurs, exceptions : ce sont eux qui départagent les options.
- Une grille pondérée avant les offres pour que la décision ne se cale pas sur la dernière démonstration vue.
Quatre options, du plus standard au plus spécifique
| Options | Adaptée quand | Limites | À vérifier |
|---|---|---|---|
| Progiciel standard paramétré | Processus standards ou réglementés : comptabilité, paie, achats courants. Mises à jour réglementaires prises en charge par l’éditeur. | Il faut adapter le processus au progiciel ; ce qui sort de son modèle reste à la main ou dans des fichiers. | Couverture des cas réels, coût des licences sur la durée, export complet des données en cas de sortie. |
| Progiciel et développements spécifiques | Le progiciel couvre l’essentiel, avec quelques règles propres à l’entreprise. | Chaque spécifique dans le progiciel se reteste à chaque mise à jour ; trop nombreux, ils la bloquent. | Nombre et nature des spécifiques, qui les maintient, compatibilité avec les montées de version. |
| Progiciel et outils sur-mesure connectés | Cœur standard dans le progiciel, processus différenciants dans des outils à part, reliés par des interfaces. | Des interfaces à surveiller ; deux sortes de compétences à tenir. | Interfaces disponibles du progiciel, alerte en cas d’échec, propriété et documentation du code des outils. |
| Sur-mesure complet | Processus qui fait la différence, volumétrie ou règles qu’aucun progiciel ne couvre, et compétences pour le faire vivre. | L’entreprise porte seule les évolutions, y compris réglementaires ; dépend de la documentation et des personnes qui le connaissent. | Propriété du code et cession des droits, remise du code source, documentation, compétences internes ou prestataire de relais. |
L’option mixte est souvent la bonne : le progiciel garde ce qu’il fait bien, le sur-mesure ne porte que ce qui distingue l’entreprise.
Les pièges fréquents
- Du spécifique dans le progiciel qui s’accumule jusqu’à rendre chaque mise à jour risquée, puis impossible : l’entreprise paie un progiciel sans en avoir les évolutions.
- Du sur-mesure sans documentation qui ne tient que par la personne qui l’a écrit ; son départ transforme l’outil en boîte noire.
- Choisir sur une démonstration préparée sur des exemples choisis, qui ne montre ni les exceptions ni les volumes réels de l’entreprise.
- Sous-estimer la reprise de données articles, clients, historiques, écritures : leur nettoyage et leur transfert pèsent souvent plus que prévu, quelle que soit l’option.
- Oublier la sortie ne pas prévoir, dès le contrat, comment récupérer ses données et son code le jour où l’outil change.
Le contrôle interne
La décision laisse une trace : la carte des processus, la grille pondérée, le chiffrage et les motifs du choix sont écrits et datés. Quelle que soit l’option, les données comptables produites par informatique doivent rester conservées et présentables sur support informatique en cas de contrôle, y compris après un changement d’outil : la reprise de l’historique fait partie du choix. Un prestataire qui traite des données personnelles pour l’entreprise doit, en fin de prestation, les restituer ou les supprimer selon ses instructions ; pour un service en nuage, le règlement européen sur les données encadre le changement de fournisseur. L’introduction d’un nouvel outil relève, selon l’effectif, de l’information et de la consultation du comité social et économique.
Par où commencer
- Lister les processus concernés et classer chacun : standard, réglementé ou différenciant.
- Fixer et pondérer la grille de critères avec la direction, la DSI et la finance, avant toute offre.
- Chiffrer le coût complet de chaque option et l’éprouver sur les cas réels, exceptions comprises, avant de décider.
Questions fréquentes
Un outil sur-mesure coûte-t-il plus cher qu’un progiciel ?
Pas toujours, et la comparaison n’a de sens que sur le coût complet : licences ou développement, intégration, reprise de données, maintenance, évolutions et sortie, sur la même durée. Un progiciel peut revenir plus cher s’il exige beaucoup de spécifique ; un sur-mesure peut l’être s’il couvre un processus standard qu’un progiciel fait déjà.
Quand le progiciel est-il clairement le meilleur choix ?
Quand le processus est standard ou fortement réglementé, que l’éditeur suit les évolutions de la réglementation, et que l’entreprise accepte d’adapter ses pratiques. La comptabilité et la paie en sont les exemples les plus courants : le calcul et la responsabilité restent dans un outil fait pour cela.
Qui est propriétaire du code d’un outil développé sur mesure ?
Celui que le contrat désigne. La cession des droits sur le code, la remise du code source et la documentation se prévoient par écrit, avant le développement ; sans cela, l’entreprise utilise un outil qu’elle ne peut ni reprendre ni confier à un autre prestataire.
Un progiciel en ligne est-il plus réversible qu’un outil sur-mesure ?
Pas par nature. Le règlement européen sur les données encadre le changement de fournisseur de services en nuage et, selon l’Arcep, interdit les frais de changement à compter du 12 janvier 2027 ; il reste à vérifier dans quel format les données sortent et ce qu’il faut reconstruire ailleurs. Un sur-mesure dont l’entreprise détient le code et la documentation peut être très réversible.
Peut-on commencer par un progiciel et ajouter du sur-mesure plus tard ?
Oui, à condition de choisir un progiciel qui expose ses données par des interfaces, et de garder le spécifique hors du progiciel. Les outils sur-mesure se branchent alors autour, sans gêner ses mises à jour.
Combien coûte une étude de choix entre ERP et sur-mesure ?
Cela dépend du nombre de processus, de services et de sociétés concernés. Un diagnostic permet de le dire précisément avant de s’engager.
Votre choix entre progiciel et sur-mesure, en diagnostic
Processus standards et différenciants, grille de critères, coût complet : un état des lieux neutre, et l’option qui convient à chaque processus.
Demander le diagnosticPour aller plus loin
Sources
- Contrôle des comptabilités informatisées, BOI-CF-IOR-60-40, 4 octobre 2017 — BOFiP-Impôts
- Règlement européen sur la protection des données, guide du sous-traitant, septembre 2017 — CNIL
- Décision n° 2025-0340 du 20 février 2025 sur les frais de transfert de données lors d’un changement de fournisseur de services d’informatique en nuage — Arcep