Réponse courte : relève du paramétrage tout ce que le produit sait déjà faire et qu’il suffit de régler ; relève du développement tout ce qu’il ne sait pas encore faire. La première catégorie se livre en jours et suit les mises à jour toute seule. La seconde se chiffre, s’arbitre, et engage votre entreprise bien au-delà de sa facture initiale.
Quelle est la différence, concrètement ?
Un paramétrage active ou règle un comportement déjà présent dans le produit : une unité de saisie, un seuil de validation, un circuit d’approbation, un champ, un rapport. Le code ne change pas ; sa configuration change.
Un développement spécifique ajoute au produit un comportement qui n’existait pas. Le code change, donc quelqu’un doit le maintenir, et quelqu’un doit décider s’il rejoint le produit standard ou vit à côté.
| Paramétrage | Développement spécifique | |
|---|---|---|
| Délai | Jours | Semaines à mois |
| Coût | Généralement inclus dans l’abonnement | Chiffré et arbitré au préalable |
| Mises à jour | Suivies automatiquement | À vérifier : intégré au socle ou porté à part |
| Réversibilité | Un réglage se change | Un développement se remplace |
| Qui le fait | Vos équipes, ou l’éditeur | L’éditeur |
Comment savoir de quel côté tombe votre besoin ?
Cinq critères suffisent à trancher dans la grande majorité des cas :
- S’agit-il d’une donnée ou d’un comportement ? Ajouter, classer ou restituer une donnée relève presque toujours du paramétrage. Calculer, contrôler ou déclencher relève plus souvent du développement.
- Le besoin existe-t-il déjà ailleurs sous un autre nom ? Beaucoup de demandes « spécifiques » sont des cas connus mal nommés. C’est la première chose à vérifier, et c’est souvent là que la discussion s’arrête.
- Combien de clients auraient le même besoin ? Un besoin partagé a des chances de rejoindre le socle, donc d’être maintenu pour vous sans que vous le portiez seul.
- Le besoin touche-t-il un écran ou une mécanique ? Un écran se règle plus facilement qu’une mécanique de facturation ou de calcul de marge.
- Que se passe-t-il si vous ne le faites pas ? Si la réponse est « on continue avec un tableur », le besoin est réel. Si c’est « on ferait autrement », il mérite d’être reposé avant d’être chiffré.
Ce que le développement spécifique coûte vraiment
Le devis initial est la partie visible. Trois coûts suivent, et ils sont rarement chiffrés au moment de la décision :
- la maintenance, si le développement vit à côté du produit plutôt que dedans ;
- le blocage de version, quand une mise à jour ne peut plus être appliquée sans casser le spécifique : c’est le scénario le plus coûteux, parce qu’il vous prive aussi de toutes les évolutions que vous n’aviez pas demandées ;
- la dépendance, quand une seule personne chez l’éditeur sait comment votre cas fonctionne.
Un développement intégré au socle du produit évite les trois. C’est la question à poser, et elle est plus importante que le prix.
Les questions à poser avant de signer
- Ma demande relève-t-elle du paramétrage ou du développement ? Et pourquoi ?
- Existe-t-il déjà un moyen d’y répondre par configuration, même imparfaitement ?
- Si c’est un développement : rejoindra-t-il le produit standard ou restera-t-il propre à mon installation ?
- Qui le maintient, et que se passe-t-il à la prochaine mise à jour majeure ?
- Puis-je l’essayer sur une base de test, sur mes données, avant la production ?
La troisième question est celle qui protège le mieux, et c’est aussi celle qu’on oublie le plus souvent.
Le rôle de la base de test
Un besoin décrit à l’oral et un besoin manipulé sur ses propres données ne sont pas le même besoin. Déployer la modification sur une base de test avant la production permet de découvrir les cas oubliés au moment où ils coûtent encore peu à corriger, et de valider, ou de demander un ajustement, sans exposer vos équipes à un réglage qui ne convient pas.
C’est aussi le meilleur moyen d’éviter le scénario le plus coûteux d’un projet ERP : un développement livré conforme à la spécification, et inutilisable en pratique.
En pratique
Chez AlibeeZ, plus de 400 règles de gestion sont déjà livrées et s’activent par paramétrage, aux côtés de sept autres leviers : champs, tags, formulaires, workflows, rapports, alertes et communication interne. Ce qui sort du paramétrage est cadré, chiffré et discuté avant d’être engagé, puis rejoint le socle du produit pour être maintenu avec lui. Le détail est sur la page personnalisation.
Questions fréquentes
Quelle est la différence entre paramétrage et développement spécifique ?
Le paramétrage règle un comportement déjà présent dans le produit : le code ne change pas, seule sa configuration change. Le développement spécifique ajoute un comportement qui n’existait pas, donc du code que quelqu’un devra maintenir.
Comment savoir de quel côté tombe mon besoin ?
Demandez-vous s’il s’agit d’une donnée ou d’un comportement. Ajouter, classer ou restituer une donnée relève presque toujours du paramétrage ; calculer, contrôler ou déclencher relève plus souvent du développement.
Un développement spécifique survit-il aux mises à jour ?
Cela dépend d’une seule chose : est-il intégré au socle du produit ou porté à côté ? Intégré, il est maintenu avec le reste et suit les mises à jour. Porté à côté, il peut bloquer votre version et vous priver des évolutions que vous n’aviez pas demandées.
Pourquoi passer par une base de test avant la production ?
Parce qu’un besoin décrit à l’oral et un besoin manipulé sur ses propres données ne sont pas le même besoin. La base de test fait apparaître les cas oubliés au moment où ils coûtent encore peu à corriger, et évite qu’un développement conforme à la spécification se révèle inutilisable.
