L’un des plus grands atouts d’Odoo est sa capacité de personnalisation. Contrairement à de nombreux ERP, il est relativement simple d’ajouter une fonctionnalité, de modifier un écran d’ajouter ou enlever une étape d’un processus ou de développer un module répondant à un besoin spécifique.
Mais cette force cache aussi un piège : parce qu’il est facile de développer dans Odoo, certains projets finissent par en faire beaucoup trop.
Odoo standard permet déjà de faire plus que l’on imagine
Au fil des années Odoo a réussi à intégrer énormément de fonctionnalités dans l’ERP, au point où il faut bien chercher dans l’interface pour les trouver. Des dizaines de paramètres de configuration sont disponibles. Des règles d’accès tellement complètes qu’on s’y perd facilement. Des rapports personnalisables, et j’en passe…
Ce grand nombre de fonctionnalités permet à la plupart des entreprises à trouver exactement ce dont elles ont besoin dans grands efforts, il suffit parfois de savoir où chercher et quel bouton cocher dans les paramètres.
Tout système informatique ayant bien entendu ses limites, il n’est pas rare de voir des utilisateurs demander un fonctionnement différent, ou qui proposent de repenser une vue.
C’est à ce moment qu’il faut se poser quelques questions :
- Ce besoin crée-t-il réellement de la valeur ?
- Est-ce une obligation réglementaire ?
- Est-ce une spécificité qui fait notre avantage concurrentiel ?
- Ou bien, essayons-nous simplement de reproduire une vieille habitude ?
Faut-il vraiment modifier Odoo ?
En effet, beaucoup de demandes d’utilisateurs ressemblent à :
- Dans notre ancien logiciel, le bouton était ici.
- Nous sommes habitués à procéder d’une autre manière, là, c’est différent.
- Il y a trop d’étapes…
Dans ce genre de cas, il faudrait commencer par comparer les deux méthodes et se demander : est-ce que la méthode d’Odoo est plus performante ? plus pratique ? ou bien est-elle tout simplement inhabituelle ?
Les processus proposés par Odoo ne sont pas apparus par hasard. Ils sont le résultat de plusieurs années d’expérience acquise auprès de centaines de milliers d’entreprises dans des secteurs très différents.
Prenons un exemple concret que j’ai rencontré lors d’un projet ERP : une entreprise utilisait pendant des années un logiciel où le bon de commande, le bon de livraison et la facture étaient en réalité un seul et même document. Seule la version imprimée changeait.
Lors du passage sur Odoo, les utilisateurs ont eu le sentiment que le logiciel était devenu inutilement compliqué : il fallait désormais créer plusieurs documents, chacun validé par un service différent.
La méthode à laquelle est habituée cette entreprise présente de nombreux défauts : manque de traçabilité, des responsabilités floues, et centralisation de tout le processus sur un seul employé.
Dans Odoo par contre, comme dans d’autres systèmes ERP, la responsabilité des documents est volontairement partagée entre plusieurs services : Un bon de commande est validé par le service commercial, un bon de livraison doit être validé au magasin, le facturier reçoit un bon de commande, un bon de livraison, les compare et établit une facture, puis envoie à l’expédition.
Chaque étape est une occasion de rattraper une éventuelle erreur. Si vous centralisez toutes ces opérations autour d’une même personne, aussi performante et compétente qu’elle peut l’être, vous perdez cette validation à plusieurs étapes en noyant un seul employé dans un processus trop compliqué pour être fait par la même personne.
Le problème ici ne vient pas du fait qu’Odoo est trop compliqué, mais plutôt du fait que l’entreprise est habituée à un processus douteux.
La limite d’Odoo standard n’est pas toujours une limite d’Odoo. C’est parfois la limite de notre volonté de changer nos habitudes.
Avant le développement, penser au no-code
Si effectivement une modification est nécessaire, il ne faut pourtant pas faire automatiquement le saut vers du développement !
Il existe en effet dans Odoo plusieurs options avancées telles que les automatisations, les actions serveur, champs personnalisés ou Studio (dans la version Enterprise).
Ces fonctionnalités, souvent méconnus des utilisateurs nécessitent certes certaines connaissances d’Odoo, mais ils sont d’une puissance étonnante !
- Lorsqu’un devis dépasse un certain montant, créer automatiquement une activité pour le responsable commercial.
- Lorsqu’un client commande douze pièces d’un certain produit, ajouter une unité gratuite à la commande.
Quelques minutes de configuration suffisent parfois à résoudre un besoin qui aurait autrement donné naissance à un module personnalisé.
Pourquoi ne passer au développement qu’en dernier recours ?
Quand les configurations natives d’Odoo ne permettent pas d’obtenir un résultat satisfaisant, quand les solutions no-code ont été étudiées puis écartées, nous pouvons seulement parler de développement spécifique.
Le développement personnalisé n’est en aucun cas une mauvaise pratique, bien au contraire, mais il doit être perçu comme dernier recours, parce que c’est une solution lourde qui revient plus cher que son coût initial !
Autrement dit :
Le développement personnalisé est un investissement, pas un réflexe.
Voici quelques points à prendre en considération :
La dépendance
Développer un module spécifique implique directement une dépendance vis-à-vis du développeur, s’il disparaît, qui maintiendra le module ?
Dette technique
Chaque module développé devra être adapté lors des futures mises à jour, certaines évolutions natives d’Odoo peuvent entrer en conflit avec le code personnalisé. Outre le coût de la mise à jour, il faut penser à mettre à jour et tester les modules personnalisés.
Complexité
Plus il y a de modules spécifiques, plus les tests sont longs, plus les bugs sont difficiles à diagnostiquer et plus les montées de version deviennent coûteuses.
Certaines entreprises évitent de mettre à jour leur ERP justement à cause de cette complexité construite le long des années, chaque nouveau module ajoutant à l’inertie de l’ERP.
Chaque développement personnalisé est une dette que vous acceptez de rembourser à chaque mise à jour de votre ERP.
Il ne faut pas oublier que les fonctionnalités fournies par Odoo, sont maintenues par Odoo. Le coût de leur maintenance est invisible pour l’entreprise, cependant, cette dernière est seule responsable des modules créés spécifiquement pour satisfaire à ses besoins.
Encore une fois, un développement personnalisé est vraiment capable de transformer un ERP en bien, quand il est bien fait, mais surtout… quand il est nécessaire !
Un bon projet Odoo n’est pas celui qui contient le plus de développements personnalisés, c’est celui qui atteint les objectifs de l’entreprise avec le moins de complexité possible.
Il est donc important de toujours se demander : avons-nous vraiment besoin de développer cette fonctionnalité plutôt que de demander, ça a l’air intéressant, pouvons-nous développer ça ?.
Avant de demander : Peut-on développer cette fonctionnalité ?, posez-vous d’abord une autre question : avons-nous vraiment besoin de la développer ?