On entend souvent dire : “Odoo est lent”. C’est une phrase qui revient après quelques années d’utilisation d’un ERP.
Mais cette phrase ne dit finalement pas grand-chose.
Odoo devient lent, d’accord, mais à quel moment ? pour quels utilisateurs ? avec combien de données ? sur quelle infrastructure ?
Et surtout : Odoo était-il lent au départ ?
Dans la plupart des cas, si Odoo était suffisamment performant au début du projet, il est intéressant de se demander ce qui a changé depuis.
Des développements personnalisés mal optimisés
C’est probablement la cause principale des ralentissements perçus dans les performances du système.
Un module personnalisé peut être un grand atout et un levier majeur pour adapter Odoo au fonctionnement de l’entreprise. Mais il peut aussi devenir un frein s’il est mal optimisé.
S’il n’est pas développé en respectant certaines règles d’optimisation et de compatibilité avec les modules natifs d’Odoo, un module personnalisé peut ralentir un processus de manière spectaculaire s’il effectue trop de traitements, s’il déclenche des opérations supplémentaires à chaque modification ou s’il répète inutilement des calculs.
Un exemple que j’ai personnellement rencontré est de voir un document de vente ou d’achat devenir de plus en plus lent au fur et à mesure qu’on y ajoute des lignes.
Imaginez un bon de commande qui fonctionne parfaitement avec quelques lignes. L’utilisateur ajoute une ligne : tout va bien. Puis une autre. Puis une autre.
Après quelques lignes, une petite roue apparaît après chaque ajout et l’utilisateur doit attendre une seconde avant de pouvoir continuer. Plus le document grossit, plus l’attente s’allonge. Avec plusieurs dizaines de lignes, chaque modification peut finir par prendre plusieurs secondes.
Le problème paraît anodin au départ. Mais lorsqu’un utilisateur doit effectuer cette opération des dizaines, voire des centaines de fois en une journée, ces quelques secondes deviennent rapidement un véritable frein à la productivité.
Dans certains développements personnalisés, un calcul ou une validation peut être déclenché à chaque modification d’une ligne. Si ce traitement devient lui-même plus coûteux à mesure que le document grossit, chaque nouvelle ligne peut demander davantage de travail que la précédente.
Le résultat est une sorte d’effet boule de neige : plus le document grossit, plus il devient lent à modifier.
Les développements mal conçus présentent encore une autre faille : Ils peuvent difficilement être mis à jour si l’on veut passer à une version plus récente d’Odoo. Il y a en effet beaucoup d’entreprises incapables de mettre à jour Odoo, à cause des modules personnalisés qui n’arrivent pas à fonctionner sur une autre version du système. C’est ce qu’on appelle dans le jargon une dette technique
Un développement personnalisé mal conçu peut rendre Odoo plus lent aujourd’hui et beaucoup plus difficile à faire évoluer demain.
Cela ne veut absolument pas dire qu’il faut éviter à tout prix les développements personnalisés, mais qu’il faut plutôt être vigilant, et vérifier, non seulement que le module en question apporte les fonctionnalités voulues, mais qu’il ne ralentit pas tout le système en apportant ces fonctionnalités.
Une infrastructure sous-dimensionnée
Que votre instance Odoo soit hébergée sur un serveur distant ou sur un serveur installé directement dans vos locaux, Odoo pourrait devenir lent si le serveur n’est pas adapté à la charge.
Un serveur est à peu de chose près un ordinateur équivalent à vos ordinateurs au bureau. Avec un Processeur, de la RAM et du stockage. Et tout comme avec les ordinateurs de bureau, si ses performances ne sont pas suffisantes ou sa configuration mal adaptée, le temps de réponse du serveur peut augmenter ralentissant toute l’application.
Si vous ressentez une lenteur dans votre instance Odoo, il est conseillé de procéder à un audit complet de votre infrastructure pour détecter si le serveur est la cause du ralentissement.
Le nombre d’utilisateurs ne suffit pas à déterminer la charge que devra supporter le serveur. Cinquante personnes qui consultent des fiches produit ne représentent pas nécessairement la même charge que vingt utilisateurs qui valident simultanément des commandes ou exécutent des opérations complexes.
Il faut donc dimensionner l’infrastructure non seulement en fonction du nombre d’utilisateurs, mais aussi des opérations qu’ils réalisent et des pics de charge auxquels l’ERP devra faire face.
Il faut notamment vérifier les ressources disponibles sur le serveur : processeur, mémoire et stockage. Mais il ne suffit pas d’ajouter de la RAM ou de remplacer le serveur au hasard. Il est important de déterminer ce qui constitue réellement le goulot d’étranglement avant d’investir dans une solution.
Le stockage mérite également une attention particulière. Sa capacité compte, mais sa vitesse peut aussi avoir un impact important sur les performances, certains supports de stockage étant plus lents que d’autres.
Il n’existe donc pas de configuration universelle garantissant de bonnes performances. Les besoins dépendent surtout de la taille de la base de données, du nombre d’utilisateurs et surtout de la charge réelle imposée à l’instance.
Une infrastructure correctement dimensionnée doit pouvoir absorber les périodes de forte activité, et pas seulement fonctionner correctement dans les conditions habituelles.
Les automatisations et traitements en arrière-plan
Odoo permet d’automatiser énormément de choses, l’on est souvent tenté de les multiplier, mais une accumulation d’actions automatisées, de tâches planifiées ou de traitements périodiques pourrait créer une charge importante.
Parfois, le problème n’est même pas que ces traitements soient particulièrement lourds : c’est qu’ils s’exécutent au mauvais moment, en concurrence avec le travail des utilisateurs.
Il faut particulièrement faire attention à ne pas surcharger le système par de nombreux traitements simultanés. Les automatisations et les actions qui s’exécutent automatiquement en arrière-plan peuvent en effet être programmées par exemple pour s’exécuter en dehors des heures de travail.
Un audit de toutes les tâches exécutées en arrière-plan pourrait faire apparaitre des tâches dont on peut se dispenser, et permettrait de mieux planifier celles qui sont indispensables.
Une base de données qui a accumulé des années de données
Après plusieurs années d’utilisation, une entreprise peut avoir accumulé des centaines de milliers de commandes, des millions de mouvements de stock ou simplement beaucoup de données historiques.
Et donc, une opération qui était instantanée avec 20 000 commandes devient moins agréable avec plusieurs millions de lignes.
Une base de données volumineuse n’est pas nécessairement un problème. Avoir beaucoup de données n’est pas un problème en soi. Une base mal exploitée peut par contre devenir problématique.
Si des données historiques datant de quelques années sont sollicitées par des opérations qui n’ont besoin que des données récentes, ces opérations peuvent devenir inutilement longues.
Une base importante n’est pas forcément une base lente. Une base mal optimisée l’est.
Si les opérations quotidiennes deviennent lentes, il vaut le coup de revoir quelques points :
- Est-ce que toutes les données sont utilisées ?
- Que peut-on archiver ?
- Que devrait-on supprimer ?
- Quelles données devraient être “séparées” des données utilisées quotidiennement ?
- Est-ce que les rapports utilisés régulièrement parcourent inutilement tout l’historique ?
Répondre à ces questions permettrait de mettre de l’ordre dans vos données tout en améliorant les performances de votre ERP.
Les intégrations externes
Dans un système d’information moderne, Odoo travaille rarement seul, il peut par exemple communiquer avec une application mobile ou une plateforme de livraison.
Un ERP performant dans son environnement de test peut devenir lent une fois connecté à tout le système d’information.
Une intégration mal réalisée peut être comparable à un module personnalisé mal optimisé en multipliant les appels à Odoo ou en provoquant des traitements inutiles.
Les travaux de synchronisation peuvent être particulièrement lourds s’ils s’exécutent inutilement pendant les heures de grande charge pour le serveur, ou si la synchronisation copie toutes les données au lieu de copier seulement les données créées ou modifiées depuis la dernière synchronisation.
Si un utilisateur vous dit : “Odoo est devenu trop lent”, la bonne question n’est peut-être pas de savoir quel ERP pourrait le remplacer.
Il faut d’abord comprendre pourquoi il est devenu lent.
Est-ce une personnalisation qui effectue aujourd’hui des traitements que le système standard ne faisait pas ? Une infrastructure qui n’a pas évolué avec l’entreprise ? Des automatisations devenues trop volumineuses ? Une base de données qui a accumulé des années de données ? Une charge qui n’avait pas été anticipée ? Une intégration qui sollicite Odoo en permanence ?
Dans chacun de ces cas, remplacer l’ERP pourrait même ne rien résoudre : le nouveau système serait installé sur la même infrastructure, alimenté par les mêmes données et connecté aux mêmes applications.
Un ERP ne devient pas nécessairement lent parce qu’il est devenu mauvais. Il peut simplement être devenu différent de ce qu’il était au départ.
L’entreprise a grandi, beaucoup de choses ont sûrement changé : les données se sont accumulées, de nouveaux processus ont été ajoutés, des développements spécifiques se sont empilés et de nouvelles applications sont venues se connecter au système.
Tout cela peut avoir un effet non négligeable sur les performances du système.
Avant de changer d’ERP, il est donc parfois plus pertinent de chercher ce qui a changé depuis le jour où il fonctionnait correctement.
C’est souvent là que se trouve la véritable cause du problème.