Votre site Odoo rame, des tâches planifiées démarrent en retard, Odoo.sh redémarre des workers, et pourtant personne n’a rien changé. Souvent, le coupable n’apparaît nulle part dans Odoo : c’est un robot qui charge les mêmes pages publiques des dizaines de milliers de fois par jour. Voici comment le repérer, ce qu’il coûte vraiment (chiffres mesurés en production), et comment l’arrêter sur Odoo.sh, où vous n’avez ni nginx ni pare-feu.
1. Un problème que l’interface ne montre jamais
Un robot ne crée ni utilisateur, ni enregistrement, ni erreur. Il se contente d’appeler en boucle quelques pages publiques : la prise de rendez-vous, la boutique, la recherche. Chaque appel coûte au serveur une page complète : ouverture de session, routage, requêtes en base, rendu.
On en voit seulement les symptômes : un site lent aux heures creuses comme aux heures pleines, des tâches planifiées qui attendent leur tour, des workers tués faute de mémoire, et la tentation de passer à une formule Odoo.sh plus chère… qui ne règle rien, puisque le robot occupera aussi la capacité ajoutée.
Les scrapers de prix, les robots de réservation et, depuis peu, les robots des IA (GPTBot, ClaudeBot, Bytespider…) suivent tous le même schéma : beaucoup de requêtes, chacune rapide, depuis une poignée d’adresses ou une même plage réseau.
💡 À retenir
Un robot n’est pas lent, il est nombreux. On ne le trouve pas en profilant une page : il faut classer les journaux du serveur par temps cumulé, URL par URL.
2. Un cas réel : jusqu’à 77 % du serveur pour un seul robot
Sur une base Odoo.sh de production que nous maintenons, le classement des journaux d’une journée a donné un résultat net : 175 000 requêtes par jour sur les pages de prise de rendez-vous, pour une cinquantaine de vrais rendez-vous. Elles venaient d’une soixantaine d’adresses d’une même plage réseau, sans reverse DNS (les moteurs de recherche légitimes en ont un), à débit constant, y compris à 4 h du matin.
Chaque requête ne prenait qu’une trentaine de millisecondes. Mais à ce volume, le robot consommait entre 61 % et 77 % du temps serveur selon les jours. Nous l’avons bloqué au tout premier point du cycle de requête d’Odoo, puis comparé deux journées équivalentes (le même jour de la semaine, avant et après) :
- temps serveur consommé par le robot : −96 % ;
- temps serveur total : −63 % ;
- minutes saturées : de 50 à 5 ;
- workers tués par le système : de 12 à 0.
Un compromis à dire honnêtement : le temps de réponse d’une page pour un visiteur humain n’a pas baissé (88,6 ms avant, 91,3 ms après). Le gain porte sur la capacité libérée et la disparition des saturations, pas sur la vitesse de chaque page.
💡 À retenir
Bloquer un robot ne rend pas une page plus rapide. Cela rend au serveur les heures de calcul qu’il perdait, et met fin aux pics qui faisaient tomber des workers.
3. Sur Odoo.sh, pas de nginx ni de pare-feu
Sur un serveur à vous, on bloque un robot avec une règle nginx ou une ligne de pare-feu. Sur Odoo.sh, vous n’avez accès ni à l’un ni à l’autre : tout ce qui arrive sur votre domaine est servi par Odoo.
Si votre domaine passe par Cloudflare et que vous pouvez en régler le pare-feu (WAF), c’est la meilleure solution : le robot est arrêté avant même d’atteindre Odoo. Mais ce n’est pas le cas de beaucoup d’installations, et les robots qui passent quand même doivent encore être traités. Il faut alors que la protection vive dans Odoo, au point le plus précoce possible.
💡 À retenir
Bloquer en amont (Cloudflare) quand c’est possible, dans Odoo sinon. Les deux se complètent.
4. Anti-Bot Rate Limiter : la même méthode, en module
Nous avons tiré de ce cas un module, disponible sur l’Odoo Apps Store pour Odoo 18, 19 et 20 (Community et Enterprise, 49 €). Il contrôle chaque requête avant l’authentification, le routage et le rendu :
- des règles par URL (
/appointment*,/shop*…), par méthode et par User-Agent, avec un quota sur une fenêtre glissante ; - un comptage par adresse ou par réseau (/24 en IPv4, /64 en IPv6) : un robot qui tourne sur toute une plage est vu comme un seul ;
- un mode Observer, qui compte ce qui serait refusé sans rien refuser, puis un mode Bloquer : réponse « 429 Too Many Requests » et bannissement temporaire du réseau ;
- des listes de réseaux toujours autorisés (vos bureaux, vos partenaires) ou bloqués ;
- un rapport de trafic par adresse et par heure, avec blocage en un clic.
Le point qui nous tenait le plus à cœur : aucune requête en base par visite. Chaque worker compte en mémoire et partage ses compteurs avec les autres toutes les 5 secondes, en un seul envoi (chaque seconde pendant une attaque). Une protection qui ralentirait chaque page n’en serait pas une. voir la fiche du module
💡 À retenir
Compter par réseau plutôt que par adresse, c’est ce qui fait la différence face à un robot réparti sur des dizaines d’IP.
5. Le mettre en place sans bloquer vos clients
Toutes les règles livrées démarrent en mode Observer : l’installation ne refuse rien. Laissez tourner une journée, lisez le rapport de trafic, puis passez en Bloquer les seules règles dont vous êtes sûr. Les utilisateurs connectés et les adresses privées (réseau du bureau, proxy) ne sont jamais comptés, et en cas de doute, le module laisse passer la requête.
Google et les moteurs de recherche ne sont pas visés par les règles par défaut. Et un « 429 » est compris par eux comme « ralentissez », pas comme une erreur.
💡 À retenir
Observer d’abord, bloquer ensuite : on ne bloque que ce que les chiffres ont montré.
⚔️ Le Match : Odoo seul vs Anti-Bot Rate Limiter
| Critère | Odoo seul | Avec le module |
|---|---|---|
| Coût d’une requête de robot | Une page complète (≈ 26 ms) | Un refus (≈ 3 ms) |
| Robot réparti sur une plage | Invisible | Compté par réseau /24 |
| Fonctionne sur Odoo.sh | — | Oui, sans nginx |
| Voir qui charge le serveur | Journaux bruts à analyser | Rapport par adresse et par heure |
| Mise en route sans risque | — | Mode Observer |
Coûts par requête mesurés sur les journaux de production Odoo.sh du cas décrit plus haut, sur deux journées comparables (même jour de la semaine), avant et après blocage.
Le Verdict : avant de payer plus de serveur, regardez qui l’occupe
Un Odoo lent n’a pas toujours besoin de plus de puissance. Il a parfois besoin qu’on lui retire un
visiteur qui n’achète rien. Le module se trouve sur l’Odoo Apps Store pour
Odoo 18,
Odoo 19 et
Odoo 20.
Vous ne savez pas ce qui ralentit votre Odoo ? Nous classons vos journaux et vous disons où part le
temps serveur, lors d’un
audit de votre Odoo.
Votre site Odoo rame, des tâches planifiées démarrent en retard, Odoo.sh redémarre des workers, et pourtant personne n’a rien changé. Souvent, le coupable n’apparaît nulle part dans Odoo : c’est un robot qui charge les mêmes pages publiques des dizaines de milliers de fois par jour. Voici comment le repérer, ce qu’il coûte vraiment (chiffres mesurés en production), et comment l’arrêter sur Odoo.sh, où vous n’avez ni nginx ni pare-feu.
1. Un problème que l’interface ne montre jamais
Un robot ne crée ni utilisateur, ni enregistrement, ni erreur. Il se contente d’appeler en boucle quelques pages publiques : la prise de rendez-vous, la boutique, la recherche. Chaque appel coûte au serveur une page complète : ouverture de session, routage, requêtes en base, rendu.
On en voit seulement les symptômes : un site lent aux heures creuses comme aux heures pleines, des tâches planifiées qui attendent leur tour, des workers tués faute de mémoire, et la tentation de passer à une formule Odoo.sh plus chère… qui ne règle rien, puisque le robot occupera aussi la capacité ajoutée.
Les scrapers de prix, les robots de réservation et, depuis peu, les robots des IA (GPTBot, ClaudeBot, Bytespider…) suivent tous le même schéma : beaucoup de requêtes, chacune rapide, depuis une poignée d’adresses ou une même plage réseau.
💡 À retenir
Un robot n’est pas lent, il est nombreux. On ne le trouve pas en profilant une page : il faut classer les journaux du serveur par temps cumulé, URL par URL.
2. Un cas réel : jusqu’à 77 % du serveur pour un seul robot
Sur une base Odoo.sh de production que nous maintenons, le classement des journaux d’une journée a donné un résultat net : 175 000 requêtes par jour sur les pages de prise de rendez-vous, pour une cinquantaine de vrais rendez-vous. Elles venaient d’une soixantaine d’adresses d’une même plage réseau, sans reverse DNS (les moteurs de recherche légitimes en ont un), à débit constant, y compris à 4 h du matin.
Chaque requête ne prenait qu’une trentaine de millisecondes. Mais à ce volume, le robot consommait entre 61 % et 77 % du temps serveur selon les jours. Nous l’avons bloqué au tout premier point du cycle de requête d’Odoo, puis comparé deux journées équivalentes (le même jour de la semaine, avant et après) :
- temps serveur consommé par le robot : −96 % ;
- temps serveur total : −63 % ;
- minutes saturées : de 50 à 5 ;
- workers tués par le système : de 12 à 0.
Un compromis à dire honnêtement : le temps de réponse d’une page pour un visiteur humain n’a pas baissé (88,6 ms avant, 91,3 ms après). Le gain porte sur la capacité libérée et la disparition des saturations, pas sur la vitesse de chaque page.
💡 À retenir
Bloquer un robot ne rend pas une page plus rapide. Cela rend au serveur les heures de calcul qu’il perdait, et met fin aux pics qui faisaient tomber des workers.
3. Sur Odoo.sh, pas de nginx ni de pare-feu
Sur un serveur à vous, on bloque un robot avec une règle nginx ou une ligne de pare-feu. Sur Odoo.sh, vous n’avez accès ni à l’un ni à l’autre : tout ce qui arrive sur votre domaine est servi par Odoo.
Si votre domaine passe par Cloudflare et que vous pouvez en régler le pare-feu (WAF), c’est la meilleure solution : le robot est arrêté avant même d’atteindre Odoo. Mais ce n’est pas le cas de beaucoup d’installations, et les robots qui passent quand même doivent encore être traités. Il faut alors que la protection vive dans Odoo, au point le plus précoce possible.
💡 À retenir
Bloquer en amont (Cloudflare) quand c’est possible, dans Odoo sinon. Les deux se complètent.
4. Anti-Bot Rate Limiter : la même méthode, en module
Nous avons tiré de ce cas un module, disponible sur l’Odoo Apps Store pour Odoo 18, 19 et 20 (Community et Enterprise, 49 €). Il contrôle chaque requête avant l’authentification, le routage et le rendu :
- des règles par URL (
/appointment*,/shop*…), par méthode et par User-Agent, avec un quota sur une fenêtre glissante ; - un comptage par adresse ou par réseau (/24 en IPv4, /64 en IPv6) : un robot qui tourne sur toute une plage est vu comme un seul ;
- un mode Observer, qui compte ce qui serait refusé sans rien refuser, puis un mode Bloquer : réponse « 429 Too Many Requests » et bannissement temporaire du réseau ;
- des listes de réseaux toujours autorisés (vos bureaux, vos partenaires) ou bloqués ;
- un rapport de trafic par adresse et par heure, avec blocage en un clic.
Le point qui nous tenait le plus à cœur : aucune requête en base par visite. Chaque worker compte en mémoire et partage ses compteurs avec les autres toutes les 5 secondes, en un seul envoi (chaque seconde pendant une attaque). Une protection qui ralentirait chaque page n’en serait pas une. voir la fiche du module
💡 À retenir
Compter par réseau plutôt que par adresse, c’est ce qui fait la différence face à un robot réparti sur des dizaines d’IP.
5. Le mettre en place sans bloquer vos clients
Toutes les règles livrées démarrent en mode Observer : l’installation ne refuse rien. Laissez tourner une journée, lisez le rapport de trafic, puis passez en Bloquer les seules règles dont vous êtes sûr. Les utilisateurs connectés et les adresses privées (réseau du bureau, proxy) ne sont jamais comptés, et en cas de doute, le module laisse passer la requête.
Google et les moteurs de recherche ne sont pas visés par les règles par défaut. Et un « 429 » est compris par eux comme « ralentissez », pas comme une erreur.
💡 À retenir
Observer d’abord, bloquer ensuite : on ne bloque que ce que les chiffres ont montré.
⚔️ Le Match : Odoo seul vs Anti-Bot Rate Limiter
| Critère | Odoo seul | Avec le module |
|---|---|---|
| Coût d’une requête de robot | Une page complète (≈ 26 ms) | Un refus (≈ 3 ms) |
| Robot réparti sur une plage | Invisible | Compté par réseau /24 |
| Fonctionne sur Odoo.sh | — | Oui, sans nginx |
| Voir qui charge le serveur | Journaux bruts à analyser | Rapport par adresse et par heure |
| Mise en route sans risque | — | Mode Observer |
Coûts par requête mesurés sur les journaux de production Odoo.sh du cas décrit plus haut, sur deux journées comparables (même jour de la semaine), avant et après blocage.
Le Verdict : avant de payer plus de serveur, regardez qui l’occupe
Un Odoo lent n’a pas toujours besoin de plus de puissance. Il a parfois besoin qu’on lui retire un
visiteur qui n’achète rien. Le module se trouve sur l’Odoo Apps Store pour
Odoo 18,
Odoo 19 et
Odoo 20.
Vous ne savez pas ce qui ralentit votre Odoo ? Nous classons vos journaux et vous disons où part le
temps serveur, lors d’un
audit de votre Odoo.