Stack · Performance
Performance & volumétrie Odoo
« Odoo est lent » n'est pas un diagnostic. C'est un symptôme, et dans neuf cas sur dix la cause est identifiable en une demi-journée — souvent un champ calculé oublié.
« Odoo est lent. » C’est la phrase avec laquelle commencent la moitié de nos audits. Ce n’est pas un diagnostic, c’est une plainte — et la première chose à faire est de la transformer en question précise. Lent pour qui, sur quel écran, à quel moment, depuis quand ?
Dans neuf cas sur dix, la cause est trouvée en une demi-journée, et elle est banale.
Les trois profils de lenteur
| Symptôme | Cause probable | Remède |
|---|---|---|
| Un écran précis, lent pour tout le monde, tout le temps | Champ calculé non stocké, ou index manquant | Stocker le champ, ou indexer |
| Tout est lent à des heures fixes | Traitement planifié, ou connecteur qui balaie | Décaler hors heures ouvrées |
| Tout est lent aux heures de pointe | Workers sous-dimensionnés | Dimensionner selon la charge réelle |
Trois causes, trois remèdes qui n’ont rien à voir. Appliquer le mauvais ne coûte pas seulement du temps : ça déplace le problème et brouille le diagnostic suivant.
Le champ calculé : le tueur silencieux
La correction est souvent triviale — stocker le champ, avec le déclencheur de recalcul qui va bien — mais elle suppose d’avoir identifié le coupable. Et on ne le trouve pas en regardant le serveur : on le trouve en profilant la requête.
Les index : après la mesure, pas avant
Odoo tourne sur PostgreSQL, et PostgreSQL fait ce qu’on lui demande. Sur une table de commandes qui a grossi pendant six ans, une recherche sur un champ non indexé fait un balayage complet.
Mais un index n’est pas gratuit : il accélère les lectures et ralentit les écritures. En poser partout « au cas où » dégrade les performances d’insertion et occupe de l’espace pour rien. On mesure, on identifie les requêtes réellement coûteuses, on indexe ce qui le mérite.
Les workers : le sous-dimensionnement invisible
C’est le cas le plus fréquent, et le plus facile à corriger. Un Odoo installé avec quelques workers, qui sert quarante utilisateurs plus les appels de trois connecteurs : tout le monde fait la queue.
Le symptôme trompeur : le serveur n’est pas saturé. Le processeur s’ennuie, la mémoire est libre, et pourtant tout rame — parce que les demandes attendent un worker libre. L’exploitant conclut qu’il faut une machine plus grosse. C’est faux, et cher.
Le connecteur qui balaie tout
Un connecteur mal écrit lit tout, tout le temps, et souvent en pleine journée. Il n’y a aucune limite de débit dans Odoo pour l’en empêcher.
Le résultat est déroutant à diagnostiquer : le ralentissement touche tout le monde, sans lien apparent avec ce que font les utilisateurs. C’est aussi pourquoi nous concevons nos connecteurs avec des lectures ciblées, des écritures par lots et des traitements lourds décalés.
Notre méthode
- Mesurer : quelles requêtes, quel temps, quelle fréquence, quels utilisateurs.
- Isoler : reproduire le cas lent sur une copie.
- Corriger un point à la fois — sinon on ne saura jamais ce qui a marché.
- Re-mesurer et livrer les chiffres avant/après.
L’étape 4 n’est pas de la coquetterie : sans mesure d’arrivée, personne ne sait si le problème est réglé ou déplacé.
Les limites, dites franchement
Le matériel ne rattrape pas une base mal conçue. Doubler le serveur sur un modèle qui recalcule tout à chaque affichage, c’est payer deux fois plus cher la même lenteur.
Certaines lenteurs sont fonctionnelles. Un processus qui exige quatorze validations sera lent, et aucun index n’y changera rien. Nous le disons — même si ce n’est pas ce qu’on nous demande.
Il n’y a pas de chiffre universel. « Combien de commandes Odoo encaisse-t-il ? » n’a de réponse que mesurée sur votre base, avec vos modules.
Pour le dimensionnement, voir hébergement.
Questions fréquentes
Odoo est lent : par où commencer ?
Par mesurer, jamais par optimiser. « Lent » ne veut rien dire tant qu’on ne sait pas quoi, pour qui, à quel moment. Une liste lente pour tout le monde en permanence, c’est un champ calculé ou un index. Un ralentissement à 9 h et 14 h, c’est un traitement planifié. Un serveur à genoux le soir, c’est un connecteur. Trois causes, trois remèdes opposés.
Un champ calculé peut vraiment mettre une base à genoux ?
Oui, et c’est le grand classique. Un champ non stocké se recalcule à chaque affichage. Placé dans une liste de 80 lignes, c’est 80 calculs, chacun pouvant en déclencher d’autres. La liste met dix secondes à s’ouvrir, et personne ne fait le lien avec la petite colonne ajoutée l’an dernier.
Faut-il ajouter des index ?
Souvent oui, mais après mesure. Un index accélère les lectures et ralentit les écritures : en poser au hasard dégrade autant que ça améliore. On identifie les requêtes réellement coûteuses, puis on indexe ce qui le mérite.
Combien de workers faut-il ?
Cela dépend des cœurs disponibles et de la charge réelle, pas d’une formule universelle. Le cas fréquent est le sous-dimensionnement : quelques workers pour quarante utilisateurs plus les appels d’API. Tout le monde attend son tour et conclut qu’Odoo est lent, alors que le serveur ne fait rien.
Combien de commandes Odoo peut-il encaisser ?
La question n’a pas de réponse hors contexte : cela dépend de vos modules, de vos automatismes et de votre matériel. Ce qui se mesure, en revanche, c’est votre base à vous — et c’est ce que nous faisons avant de promettre quoi que ce soit.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.